LINUX.ORG.RU

Как лучше реализовать?

 , ,


0

1

Есть таблица users_projects, в ней поля user_id, project_id, и еще несколько булевых флагов и коэффициентов задаваемых ручками в админке.

Эта таблица определяет доступность проектов конкретному пользаку.
Оно выбирается галочками в админке в одном месте.

Однако, булевые флаги и коэффициенты указываются в совершенно другом разделе админки.
Т.е. только после отметки нового доступного проекта, становится возможность проставить эти флаги и коэффициенты.

Но галочки только явно определяют есть ли запись в этой таблице или нет.
В таком раскладе (в данный момент), при обновлении связей, уничтожаются проставленные коэффициенты.
А хотелось бы чтобы даже после удаления доступа к проекту система запоминала предыдущие введенные коэффициенты и при восстановлении доступа к ранее удаленному проекту восстанавливались и эти коэффициенты.

Как лучше реализовать?

1) Добавить поле is_enabled и проверять наличие записи в этой таблице и если галочку снимают, тогда просто ставить в это поле false, соотв в выборку добавить условие на is_enabled.

2) Добавить еще одну таблицу и джойнить её где надо и следить за её наполнением отдельно.

3) Другие варианты...

Ответ на: комментарий от Sorcerer

Не, история не нужна. Нужна тупая защита от случайного удаления доступа.

А почему не второй вариант? И в первом и во втором вариантах нужны будут дополнительные выборки и поиск пересечений.

Я не настаиваю на втором варианте, просто интересны причины выбора первого.

deep-purple ★★★★★
() автор топика

По моему опыту, который вообще никак не относится к веб-деву, «удалять» лучше флажком, и только в случае большого числа «удаленых» записей проводить реальную очистку. И флажок кстати лучше ставить datetime-ом, чтобы понимать дату удаления, этим можно пользоваться например при реальной очистке этих записей.

staseg ★★★★★
()
Ответ на: комментарий от deep-purple

И в первом и во втором вариантах нужны будут дополнительные выборки и поиск пересечений.

А где в первом варианте дополнительные выборки и пересечения?

staseg ★★★★★
()
Ответ на: комментарий от deep-purple

А почему не второй вариант?

А зачем, если можно проще? Запись таблицы представляет собой особенности связи двух объектов. Можно, конечно, делать по отдельной таблице хоть на каждую особенность, только зачем? Это ненужное усложнение.

Sorcerer ★★★★★
()
Ответ на: комментарий от staseg

С клиента в бекенд прилетают только: айдишник юзера и список айдишников проектов которые отмечены.

На бекенде как ни крути придется предварительно выбрать список всех отмеченных у этого пользака (наличие записи в таблице) в БД проектов. И сравнить с тем, который прилетел от клиента. Собрать те, которые подлежат удалению/выключению, собрать те, которые подлежат вставке (новые). И затем выполнить запрос (WHERE IN(...)) на удаление/выключение, а потом еще один на вставку новых доступов с дефолтными коэффициентами.

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от Sorcerer

Вот я и думаю.. А вдруг завтра у манагеров зачешется левая пятка, и им захочется еще одну «боковую» особенность прикрутить?

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от deep-purple

Ну и прикрутишь ее в эту же таблицу. Как по мне, за множеством таблиц следить и поддерживать консистентность будет намного сложнее, более того ты сам в некотором смысле будешь эту консистентность нарушать, удаляя связь, но сохраняя часть свойств этой связи.

staseg ★★★★★
()
Ответ на: комментарий от staseg

Значит ты тоже за первый вариант.. Ну, я таки честно сказать, когда создавал этот тред, то уже реализовал первый вариант. Но подумал, что, вдруг я не правильно сделал. А так, вон, три головы подумали про первый. То пусть и будет.

Спс за ответы. Отмечаю решенной.

deep-purple ★★★★★
() автор топика

1-й т.к:
С точки зрения реляционной алгебры варианты 1 и 2 идентичны
С точки зрения производительности распространенных СУБД 2-й вариант медленнее
С точки зрения сложности поддержки 2-й проигрывает, т.к. допустит ошибку легче.

German_1984 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.