[SQL]Хранение отношений many 2 many

iakobi91

Такой вопрос, к примеру есть база с количеством отношений m2m между двумя таблицами порядка 20-30. Ясно, что для них нужно заводить отдельную табличку ID, PARENT1_ID, PARENT2_ID.
А не лучше ли будет, чтобы не плодить столько мелких таблиц, завести одну ID, PARENT1_ID, PARENT2_ID, TABLE1, TABLE2, где табле - указание на таблицы, к которым относится данное соответсвие?
Кста и как лучше именовать такие таблицы?

katrin2201

в общем случае нет, не лучше
зы тогда уж лучше сделать всем сквозные айдишники из одного сиквенса и забить на тейблы _1 _2
и ID не нужен, нужен композитный ключ.

Dasar

А не лучше ли будет,

сложнее средствами базы ссылочную целостность проверять.
запросы тяжелее получаются

Кста и как лучше именовать такие таблицы?

что-нибудь типа man_car, man2car

katrin2201

что-нибудь типа man_car, man2car

мне нравится man_has_car =)

0000

Реально использовалась похожая хрень. Таблица имела 4 столбца:
1. id строки
2. id первой таблицы
3. id второй таблицы
4. Тип связи - char(1). По типу связи можно было понять что за таблицы связываются и каким отношением.
Разумеется так укладывались в таблицу только схожие сущности.
В принципе усложнение SQL запросов незначительное, но была беда в том, что в разных таблицах связи использовались разные обозначения.
P.S. Таблицы имели названия ОписаниеСвязи_LINK.

iakobi91

Еще возможен вариант, когда между двумя таблицами есть два вида связностей, тогда надо еще одно поле заводить. В общем, бредовая идея, лучше куча таблиц. Я пока именую M2M_TableName_LinkName

0000

В той реализации просто добавлялась новая буковка в возможные значения типа и связывалось по ней.
Злоупотребления не было - максимально использовалось 8 типов связи, обычно 4.

nekaya

Кста и как лучше именовать такие таблицы?

называй "_1CJOURN",
такая же хрень получится, объектная база на реляционной платформе.