Оправдано ли дублирование полей в БД?

Question

[Neabramovich]

Здравствуйте!
Есть проект на Yii2, реализующий некий веб-интерфейс для зарегистрированных компаний-клиентов. Структура БД примерно такая (одна из цепочек):

Компания -> Отдел -> Сотрудник -> Телефон

Соответственно, когда сотрудник компании-клиента логинится на сайте, в своем личном кабинете он может видеть список всех сотрудников, отделов и телефонов, принадлежащих его компании.

Реализовал это путем добавления во все таблицы (отделы, сотрудники, телефоны) отдельного поля company_id для однозначной привязки к конкретной компании. Т.к., например, при выводе всех телефонов, принадлежащих одной компании в GridView, пришлось бы строить сложный запрос, чтобы по цепочке от телефона к компании определить, принадлежит ли этот номер данной компании, или нет.

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

Правильно ли я сделал? :)

Answer 1

[nelson]

Есть два подхода к организации БД:
1) нормализация - убирает любое дублирование, гарантирует что у вас не будет неконсистентных данных в случае их изменения, минимизирует объем данных и упрощает их обновление.
2) денормализация - наоборот, дублирует данные, для удобства и быстроты их чтения. Очень часто используется для highload.
Хороши оба подхода, но каждый решает свои задачи, у обоих есть и плюсы и минусы.

Вам же надо решить, что вам проще реализовать:

• или сложные выборки и простое обновление (выбирайте нормализованную схему)
  
• или простые выборки и сложное обновление сразу в нескольких таблицах, поддержка всех этих связей (выбирайте денормализованную схему)
  

Comments

[Neabramovich]

Учитывая, что у меня в каждом контроллере по умолчанию сразу определяется текущий company_id, усложнение можно считать незначительным.
Спасибо, что развеяли мои сомнения :)

[nelson]

Усложнение в том, что если у сотрудника изменится companyid, то Вам надо будет поменять companyid и у тех телефонов, которые на него привязаны.

[Виталий Хоменко]

Хорошо написано.

[Neabramovich]

nelson: Да, верно. Но, исходя из текущей бизнес-логики, перемещений объектов между компаниями не предполагается.

Answer 2

[Arris]

Сравните выгоду от избыточности (скорость, в частности) и накладки от усложнения структуры (скажем, нужно обновлять на одно поле больше).

Answer 3

[Растишка]

На MySQL делал так же, все нормально.

Но в Postresql, насколько мне известно, можно давать права на определенные строки в таблицах, скорее всего так будет правильнее.

Answer 4

[Сергей]

Главная задача любой программы - работать быстро. Если без дублирующегося поля приходится делать более сложные запросы, которые выполняются намного дольше, то есть смысл в дублировании. Я неоднократно изначально "вылизывал" базу на этапе проектирования, исключая любое дублирование. Когда нагрузка достигала определенных величин, сервер переставал справляться с некоторыми запросами и слегка притормаживал. Анализ запросов показал, что добавление одного лишнего поля в одну-две таблицы позволит запросы сократить весьма значительно. Объемный пакет операций, который раньше занимал 1,5-3 минуты, стал отрабатываться за 5-10 секунд. Нормализация может быть хороша при достаточных объемах памяти, процессорных мощностях, определенном количестве пользователей. В реальных организациях зачастую ресурсы небезграничны и оптимизация приводит к дублированиям и увеличению объема данных в угоду скорости.

Comments

[Neabramovich]

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