Для правильного вопроса надо знать половину ответа
Взять того, кто придумал такую структуру базы, оторвать руки и поменять их с ногами, чтобы сразу было видно.
А если изменить уже ничего нельзя, то повесить на `client` триггер AFTER UPDATE, в котором менять остальные таблицы.
Спасибо за ответ.
Базу проектировал не я. Но, вижу в этом следующую логику:
1) При select-ах не требуется каждый раз делать join
2) При update не надо делать лишний запрос, чтобы проверить на самом деле данный менеджер имеет право на запись туда.
3) Так банально быстрее работает
4) Меньше строк кода
Получается 4 плюса и один минус – избыточность. И вот еще один минус возник при вопросе из сабжа.
pcdesign: Не совсем понятно. То есть в manager_id записан тот, кто имеет право изменить фамилию, имя или телефон клиента? И это могут быть разные менеджеры?
А клиент, судя по структуре, может иметь несколько имён и несколько фамилий, причём каждую из фамилий может менять свой менеджер?
Это просто бред какой-то. Я понимаю, что номеров телефонов может быть несколько, но вот имя и фамилия должны быть полями в базе клиентов. И права изменять данные должны быть, наверное, не у одного менеджера.
Может быть это поле, где запоминается тот, кто последним менял значение? Но и тогда можно сделать гораздо лучше, сохраняя в отдельную таблицу журнал изменений с идентификатором того, кто эти изменения внёс.
Rsa97: Конкретный менеджер, который "ведет" клиента - имеет право менять его фамилию, телефон и прочее. Другие менеджеры не имеют право это делать.
Структура на картинке, она просто для примера, чтобы быстро понять о чем идет речь, а не реальность.
Скажите, почему не ограничиться manager_id только в таблице client?
Неужели сложно делать один JOIN? У вас же уже есть связь между таблицами по client_id...
Простой
