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. Вот лучше этот один запрос напишите, тогда и поговорим о реляционной алгебре ;-)

Кот МатроскинВы постоянно выдвигаете какие-то нелепые тезисы про него - то дублирования записей нельзя избежать, теперь вот перед join-ом что-то проверять надо...
Почему же они "нелепые"? Вы так и не привели пример, как можно ограничить возможность ссылаться другим subtype-таблицам на одну и ту же запись supertype-таблицы.

Окей, если мой вопрос по джойнам "нелеп", как вы выведете список товаров всех типов?)))