Как смоделировать базу данных с большим количеством отношений m: n в таблице
В настоящее время я настраиваю базу данных, которая имеет большое количество отношений «многие ко многим». Все отношения моделировались с помощью таблицы ссылок. Пример:
Человек выполняет несколько работ, работа выполняется определенным количеством человек. У человека есть несколько домов, дома заняты количеством человек. У человека есть несколько ресторанов, которые ему нравятся, в ресторанах есть несколько человек, которым нравится ресторан.
Сначала я разработал это следующим образом:
Таблицы: Person, Job, House, Restaurant, Person_Job, Person_House, Person_Restaurant.
Отношения 1 - n: Человек -> Человек_Задание, Человек -> Человек_Дом, Человек -> Персонал_Ресторан, Работа -> Человек_Задание, Дом -> Персона_Дом, Ресторан -> Персонал_Ресторан.
Это довольно быстро приводит к многолюдному и сложному Модель ER.
Пытаясь упростить это, я смоделировал ее следующим образом:
Таблицы: Person, Job, House, Restaurant, Person_Attributes
Отношения 1 - n: Person -> Person_Attributes, Job -> Person_Attributes, House - > Person_Attributes, Restaurant -> Person_Attributes
Таблица Person_Attributes должна выглядеть примерно так: personId jobId houseId restaurantId
Если существуют отношения человек-работа, я добавлю запись вида:
P1, J1, NULL, NULL
Если существуют отношения человек-дом, я добавлю запись вида :
P1, NULL, H1, NULL
Таким образом, таблица атрибутов во втором примере будет иметь такое же количество записей, как и добавленные таблицы ссылок в первых примерах.
Это упрощает модель ER. , и пока я создаю индексы для personId + jobId, personId + houseId и personId + restaurantId, я думаю, это не сильно повлияет на производительность.
Мои вопросы: Второй метод - правильный способ моделирования этого? Если нет, то почему? Правильно ли я говорю о влиянии на производительность? Если нет, то почему?
Пример MySQL Workbench того, что я имею в виду, можно найти здесь: