Ennor Tiegaeltip78вы всё пытаетесь привязать к корзине какие-то события, которые непременно надо обрабатывать отдельно от заказа,
но их НЕТ. И это ключевой момент.Наоборот - это у заказа есть действия, которые отсутствуют у корзины. Я писал, что атрибуты тоже отличаются - для корзины будет достаточно ( CustomerId, ItemId , Count); для детали заказа, очевидно, нет. Или это только мне очевидно, и надо реально объяснять?

Что вы действительно упускаете, так это лес за деревьями. Данные в корзине по природе своей временные. Лично мне в базе они вообще не нужны - строго говоря, для них даже РСУБД не нужна, достаточно простейшего blob list. Поэтому я выношу таблицу корзины в отдельную БД, ставлю ей simple recovery и экономлю на бэкапах лога (в оракле, вроде бы, можно на уровне таблиц логирование отключать). Если что-то гавкнется, то потери будут минимальны и не критичны.

Ennor Tiegaeltip78в4, через какое-то время незаконченные удаляютсяЕсли каждый заказ - это событие, то возможно. Когда их сотни тысяч в день, удаление из такой таблицы будет вести к фрагментации, а ребилдить индексы в 24*7 системе обычно непросто. Мне здравый смысл подсказывает, что можно сэкономить на дефрагментации, не записывая туда данные, которые могут быть впоследствии удалены.

вы правильные вопросы поднимаете ) Когда будете писать свой магазин, они вам пригодятся.
Объясняю:
1. когда вы посчитаете эти 100000 корзин, то окажется, что средний размер = 25 байт. Потому что там кроме нескольких цифр ничего нет.
По-сравнению с еженочными обновлениями товаров от поставщиков это просто ПЫЛЬ.
Если вас всё ещё что-то беспокоит, то "CREATE TABLE tbl (...) WITH (fillfactor = 90)" и autovacuum закроют для вас эту тему навсегда.
Ну и потом, не надо их выкидывать прям так сразу, они вернутся, надо только верить ))
зы: кстати, вы и персонал от клиентов отдельно держать хотите?

2. blob-list сложно/невозможно анализировать. А это информация, она нужна.
Отдельная БД? ("горизонтальное масштабирование - ЗЛО " - цитирую разработчиков, видео ниже). *ять мы же только что про доп.таблицу говорили, а уже отдельная БД?? АСТАНАВИТЕСЬ!!1

3. "Данные в корзине по природе своей временные."
Если корзина становится заказом, то они вечные.

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

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

таки нет, это ВЫ полезли в размножение таблиц и теперь хотите каких-то решений, чтобы не выяснять типы во всех таблицах.
Разбили зачем-то корзину и заказ...
ок, у EAV есть проблемы с джойнами (много джойнить много данных) и с запутанными запросами из третьих таблиц,
но "flat", в который вы полезли, ещё хуже и мне не интересно такие задачки решать.

Магенто может и отказался от EAV, но вот это структура их БД:


Кстати, Космодемьянский ругал EAV тут (11:20):

BspleskМожет просветит неразумного, а то мы все jsonb мучаем, и уже до jquery добрались, и огребаем по полной в надежде на развитие PG.
полагаю вы про Jsquery