Вот есть такой теоретический вопрос о реляционных связях между гетерогенными структурами данных. Матюк страшный, но на самом деле всё просто и такая проблема довольно часто возникает на практике, например в интернет-магазинах, всевозможных CRM-системах и не только.

Суть проблемы можно пояснить на примере того же банального интернет-магазина. Есть множество таблиц разных товаров, потому что набор свойств (атрибутов) у них разный. Например, булка хлеба и како-нибудь девайс. Вопрос - как положить в корзину и то, и другое, и пятое-десятое? Самое простое, что приходит в голову - это в таблице корзины выделить одно поле под айди товара, а другое - под ... (барабанная дробь) ... НАЗВАНИЕ ТАБЛИЦЫ, к которой относится этот айдишник. Но это же костыль-костыльный... Потому что никаких реляционных связей тут не построишь.



Мне в голову приходит только два типичных решения - это либо использования паттерна EAV (entity, attribute, value), либо все уникальные атрибуты каждого из видов товара держать в поле с особым типом данных - JSON/JSONB, как в БД PostgreSQL. Тогда, естесственно, сущность (таблица) будет одна и её можно спокойно класть в корзину.

Так вот интересно, существуют ли какие то более элегантные решения этой проблемы?

982183"Множество таблиц2 - глупость несусветная.

Множество таблиц - это и есть паттерн Flat tables, который описан в приведенной вами ссылки (кстати, спасибо за ссылку)

982183Таблица связей (чаще всего групп связей)

А вот про таблицу связей можно подробнее?

Ennor TiegaelПро supertype-subtype слышали?
Описанный мной костыль и есть паттерн supertype-subtype, разве нет?

Кот МатроскинНет. В означенном паттерне нет никаких tablename

Атрибут TableName в моём случае играет роль Type, суть одна. Это антипаттерн, так как смешиваются данные и метаданные. Другими словами, средствами РСУБД невозможно исключить ситуацию, когда в двух и более таблицах подтипа внешний ключ указывает на одну запись супертипа. В этом случае изменение типа приводит к нарушению ссылочной целостности

Кот МатроскинМожет, суррогатный ключ - это тоже антипаттерн? :)
Да, суррогатный ключ - это тоже метаданные, но не смотря на то, что этот атрибут содержится в сущностях наряду с другими, в РСУБД, ключи обеспечены механизмами обеспечения ссылочной целостности через наложение ограничений (constraints).

Кот Матроскинвключаете поле Type в ключ, накладываете на него соответствующие ограничения в каждой из subtype-таблиц
Интересно, как вы себе представляете эти "соответствующие ограничения"?))
Вот, например, физическая модель, из которой видно, что любая из subtype-таблиц может ссылаться на одну и ту же запись в supertype-таблице:


Кстати, если это не костыль, то напишите JOIN-запрос для такого кейса)))

По поводу тезиса "делать по таблице на каждый вид товара - это самое тупое, что только можно придумать", отвечу сразу, чтоб закрыть этот вопрос. Есть такая штука, как компромисс между гибкостью и производительностью. Если гибкость не нужна, то юзаем Flat Tables, если нужна - EAV, NoSQL etc. И. кстати, кроме НФ есть ещё такое понятие как денормализация , которую как раз и применяют для оптимизации производительности.

Dimitry SibiryakovBspleskда много join

join в EAV - тормоза для тех, кому лень программировать обработку наборов данных на
клиенте. Дельфийским мышекликателям настоятельно не рекомендую.

это как? выгребать все данные потаблично и джойнить на клиенте?? о_О

982183Там же и описываются громадные недостатки этого метода.
registerersА вот про таблицу связей можно подробнее?
А связь номенклатуры и атрибутов вы хранить где думаете?
Не совсем понимаю, о чём вы. Вместо тысячи слов лучше нарисуйте пример диаграммы на draw.io