Несколько соединений «многие ко многим» в реляционной базе данных: множество таблиц с внешними ключами или одна таблица без - PullRequest
0 голосов
/ 01 октября 2019

В настоящее время у меня есть 2 типа сущностей, которые не наследуются друг от друга - назовите их A и B, и мне нужно создать направленные отношения «многие ко многим» между каждым из них. База данных в этом случае оказывается MySQL. Я ищу объективные за и против для вариантов 1 и 2, в дополнение к тому, что я перечислил до сих пор. Может быть, даже вариант 3, который является предпочтительным.

Вариант 1 - отдельная таблица для каждого типа сущности, в которой указан жестко закодированный внешний ключ

Table 1:
 - From_A int FK
 - To_A int FK

Table 2:
 - From_A int FK 
 - To_B int FK

Table 3:
 - From_B int FK
 - To_A int FK

Table 4:
 - From_B int FK
 - To_B int FK

Параметр2 - Одна таблица для каждого соединения

Table 1:
 - From int
 - From_Type int FK
 - To int
 - To_Type int FK

Table 2:
 - ID
 - Type_Name

Pro Вариант 1 / (Вариант 2 не имеет этих профи):

  • FKограничения предотвращают неправильный ввод данных
  • Кэши пула буферов InnoDB Отношения FK
  • Каркас ORM автоматически подхватит соединения

Pro option 2 / (Option1 не имеет этих профи):

  • Требуется выполнить поиск меньшего количества таблиц, чтобы найти все отношения сущности
  • Масштабируемость - количество таблиц, необходимых дляМногие отношения не будут расти квадратично. Если у меня есть 3 типа сущностей, мне все еще нужна 1 таблица вместо 9. Если у меня есть 4 типа сущностей, мне понадобится 1 вместо 16

1 Ответ

1 голос
/ 07 октября 2019

У меня был бы один стол Types.

Затем таблица Entity с типом FK.

Каждый Entity имеет 1 тип (т.е. от 1 до 1).

Затем, чтобы связать сущности вместе, настройте таблицу связей. Два столбца, оба FK каждой сущности. Это не дает вам никаких дополнительных таблиц и является гибким.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...