Имеется небольшой проект с набором таблиц ( Пользователи, товары и тд. ). Некоторые из них имеют связь многие ко многим. В связи с этим предполагается модель связи с полями: id_первой_сущности, id_второй_сущности, но так как самих отношений много, то получается, что таких промежуточных таблиц получается несколько.
Можно ли реализовать одну большую таблицу со всеми связями( так как набором полей не отличаются ), добавив поле тип_связи, и производя выборку конкретных записей в проекте уже по данному типу? Либо иметь больше, но меньших по размеру таблиц предпочтительней?
Если вы сделаете идентификаторы каждого объекта уникальным в рамках своей БД, то вы можете обойтись одной таблицей связей и в JOIN не нужно будет дополнительно указывать тип связи.
Например: Объекты типа A имеют идентификаторы вида A1, объекты типа B - B1 и тд. Тогда:
Таблица A
A1 Данные 1
A2 Данные 2
A3 Данные 3
Таблица B
B1 Данные 1
B2 Данные 2
B3 Данные 3
Таблица C
C1 Данные 1
C2 Данные 2
C3 Данные 3
LNK Таблица связей
A1 B1
A1 B3
C3 B2
и тд
Запрос на связи A и B (примерно, без синтаксического разбора):
SELECT * FROM A JOIN LNK ON A.id = LNK.id1 JOIN B ON LNK.id2 = B.id
Нужно ещё учесть, что при таком подходе у связей есть направленность: могут быть связи A1-B2 или B2-A1 и нужно иметь это ввиду: либо дублировать при добавлении, либо использовать другие подходы, либо может быть вам направленность связей как раз и нужна.
Для идентификаторов можно использовать GUID - он гарантированно не будет пересекаться между таблицами, но что-бы определить тип объекта по GUID вам нужно прошерстить все таблицы.
Можно ли реализовать одну большую таблицу со всеми связями( так как набором полей не отличаются ), добавив поле тип_связи, и производя выборку конкретных записей в проекте уже по данному типу?
Можно, только вы не можете построить внешний ключ без бубна и в JOIN нужно будет добавлять условие с "тип_связи".
Лучше и читабельнее по таблице на M<->M.
Простой
Простой
