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

Ennor TiegaelВообще ничего общего.

Делается одна таблица, условно говоря Products, которая выступает корнем вашей товарной иерархии. Туда можно поместить атрибуты, общие для всех (или почти всех) видов товаров: название, внутренний код, вес, Д*Ш*В, (возможно) цена и т.д.

На эту таблицу ссылаются все остальные товарные категории, причем первичный ключ из нее можно наследовать и использовать в качестве ключа в самих дочках.
Разве в моём примере не так?)))

Ennor TiegaelНа эту же таблицу будет ссылаться корзина. Только вот, зачем у вас корзина ссылается на заказы? Во всех магазинах, какие я видел, если товар лежит в корзине, значит заказ на него еще не существует, ммм? Корзину лучше сделать М:М связкой между Products и Customers, как у всех.
Связь между заказами и товарами в корзине должна же быть в любом случае. Также должна быть связь между заказами и покупателями. В таком случае возникает избыточность и цикличность связей: товары в корзине связаны с покупателями непосредственно и через заказ.

Кот МатроскинТут есть Type в составе ключа Product?
Вы имели в виду что-то вроде этого?


Но тогда возникает вопрос - как обеспечить константность значений полей SubA.Type, SubB.Type, и как быть с суб-таблицами при удалении соответствующих типов?

Кот МатроскинНе понял. Вы хотите убить тип "ProductB", но при этом сохранить таблицу ProductB? А какой в этом физический смысл?
Наоборот, я не хочу сохранять эту таблицу))) В том то и дело, что не существует механизма удалить таблицу автоматически и это нужно делать только в приложении

Кот Матроскинregisterersпропущено...

Наоборот, я не хочу сохранять эту таблицу))) В том то и дело, что не существует механизма удалить таблицу автоматически и это нужно делать только в приложении
Не вижу проблем в пустой таблице (очиститься-то она у Вас очистится при ON DELETE CASCADE).
Да, в реляционной модели при очистке родительской таблицы подчиненные таблицы автоматом не дропаются - при удалении всех заказов таблица элементов заказов тоже не дропается, если такое поведение требуется - надо прописывать руками. Если Вы это считаете серьезным недостатком - ну да, РСУБД Вам подходят не очень.
Вот! Что, собственно, и требовалось доказать. Всем спасибо за ответы!

tip78registerersпропущено...

Вот! Что, собственно, и требовалось доказать. Всем спасибо за ответы!
не это, а то что ваша архитектура БД - дичь
Это не "моя ахритектура", а доказательство того, что Flat table - это антипаттерн))

Ennor Tiegaelregisterers,

Вы хоть что-нибудь по теории РСУБД читали? Жесть какая-то, просто.

Еще раз: заказ не существует, пока пользователь не сказал оформить его. Зачем ссылаться на несуществующую сущность, а главное, что вам дает эта связь?

Ну и наконец, если пользователь захочет отправить содержимое корзины по нескольким адресам - как у Амазона, "Deliver to multiple addresses" - придется проделывать кучу дополнительных телодвижений.
Где вы увидели "жесть"? Связь в корзине между продуктом и заказом появляется после его оформления. То есть поле Cart.OrderId может быть nullable, что является признаком того, что товар добавлен в корзину, но ещё не оформлен

tip78любители хранить корзины отдельно, какую ценность для вас несёт первозданная корзина ДО кнопки "оформить заказ" ?
после звонка менеджера выяснится, что чего-то нет, что-то забыли доложить, что-то надо заменить
важны не эти изменения, а только ОПЛАЧЕННЫЙ ЗАКАЗ = транзакция: -товар +деньги
а зачем плодить "черновики"?
Бугога)) А по какому признаку вы собираетесь агрегировать товары в таблице? По времени добавления в корзину?)))

982183Скорее моветон.
Так а можете предложить что-то лучше?)
Например, как писалось выше, EAV не совсем уместен, когда видов товара, скажем 2-3, но много записей самих товаров. Поэтому Flat table здесь как бы больше подходит, но обладает своими недостатками, о которых я писал.
Ну, как более универсальный вариант - это хранение атрибутов товаров в новомодных хипстерских штучках вроде NoSQL

tip78Dimitry Sibiryakovпропущено...

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

"упадёт" она, только если вы её удалите
так вот не удаляйте.
и не придётся лепить кучу ненужных таблиц

Вы вообще в курсе о существовании такого понятия как нормальная форма и зачем это?))

tip78registerersпропущено...

Бугога)) А по какому признаку вы собираетесь агрегировать товары в таблице? По времени добавления в корзину?)))
по id, например
:рукалицо:
нормальную форму бегом гуглить, пока ваше понимание "таблиц" и "реляционности" не придёт в норму
Вы же как раз и предлагаете денормализовать)))

Кот МатроскинregisterersНо тогда возникает вопрос - как обеспечить константность значений полей SubA.Type, SubB.Type,

Ограничениями (check), я же сказал. У разных СУБД механизм отличается, но не сильно.
Интересно, а какие техники реализации существуют? Например, мне приходит в голову только определение в subtype-таблице поля с ненулевым дефолтным значением TypeId и убрать update/insert из грантов (конечно, если это PostgreSQL). Но это тоже пахнет костылём, ибо дефолтное значение - это часть DDL, т.е. метаинформация, а конкретное значение id supertype-таблицы - это данные.
Так что не так всё просто, как вы рисуете...

tip78registerersВы вообще в курсе о существовании такого понятия как нормальная форма и зачем это?))
в профили заглядывайте иногда
вам бы тут не выёживаться надо, а всасывать каждую букву, коли за помощью пришли со своими дикими идеями
Вот только давайте без обид и без снобизма, только по сути)) Эмоции часто вредят продуктивной дискуссии. А форумы, кстати, существуют не только для помощи, но и для обмена идеями. Бинго! Просто хочется разобраться в теоретических вопросах, думаю, не только одному мне это интересно. А теперь по сути объясните, почему то, что вы предлагаете не является денормализацией?

tip781. МЫ тут не ради ваших "квадратных велосипедов идей". Зачем нам деградировать?? В этой теме ВАМ вправляют мозги, а вы наполняетесь счастьем.
Да не бойтесь вы, мышление ещё никогда никого не привело к деградации)) Вот и вправьте мне мозги, ответив на мой вопрос топика, а не уходя от него ;-)

tip78Просто напомню, что мы находимся в теме с названием, которое вы придумали на полном серьёзе - " РЕЛЯЦИОНКА ТУТ БЕССИЛЬНА? ", где под " ТУТ " подразумевается довольно банальная схема EAV,
Поэтому я и говорю, читайте внимательно первый пост и последующие. Под " ТУТ " подразумевалась конкретная задача, которая часто встречается, а EAV - всего лишь один из способов решения задачи. Собственно, целью сабжа было прояснить, какие вообще подходы к решению задачи существуют и насколько они эффективны. Не зря же придумали документно-ориентированные СУБД. Понимаю, что тема холиварная, но давайте обмениваться аргументами, а не эмоциями!

tip78 а конкретно, вы не осилили и извратили элементарное хранение товаров со множеством атрибутов (которые по сути являются свойствами).
Т.е. вы своей задачкой для 5 класса просто обоссали всю реляционную алгебру и триллионы человеко-часов довольно неплохих математиков заявив, что они её не тянут.
Это не я извратил, это существующий паттерн Flat table костыльный, о чём я и писал (создаётся впечатление, что вы вообще не читали предыдущие посты). И да, есть красивая реляционная теория, а есть суровая практика и я не один раз встречал в ней решения на основе EAV, которые ложили апп на овер 100к айтемов. Поэтому рефакторили такие системы, в том числе применяя денормализацию. Кстати, Magento, тоже отказалась в свое время от EAV.

tip782. а теперь по сути:
Вот так бы и сразу)) Спасибо за ваш SQL-код, вижу, что вы старались. Но это почти оффтоп. Корзина в поставленной задаче не главное, логика её работы - отдельная тема. То кому-то что-то не понравилось и понеслось... Я вообще пример с магазином придумал потому что он многим знаком. Суть же задачи, которую я ставил состоит в том, возможно ли в денормализованных архитектурах БД выдержать условия однозначности и непротиворечивости реляционных связей? В случае Flat table (type-supertype), это невозможно, что было показано выше. Представьте, у вас есть родительская (supertype) таблица и две дочерние (subtype). Для определения того, с какой из дочерних таблиц заджойнить родительскую, нужно сначала проверить в ней значение поля Type. Вот лучше этот один запрос напишите, тогда и поговорим о реляционной алгебре ;-)