Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Проектирование БД Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7      [все]
 Реляционка тут бессильна?  [new]
registerers
Member

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

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

Картинка с другого сайта.

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

Так вот интересно, существуют ли какие то более элегантные решения этой проблемы?
11 сен 17, 03:25    [20785530]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
982183
Member

Откуда:
Сообщений: 917
registerers
Есть множество таблиц разных товаров, потому что набор свойств (атрибутов) у них разный.

"Множество таблиц2 - глупость несусветная.
Есть стандартное решение.
Таблица товаров
Таблица свойств.
Таблица связей (чаще всего групп связей)
11 сен 17, 04:00    [20785535]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
982183
Member

Откуда:
Сообщений: 917
Погуглите проблему.
Десятки раз она обсасывалась.

[url=]https://zlob.in/2013/01/struktura-tablic-dlya-kataloga-tovarov-internet-magazina/[/url]
11 сен 17, 04:05    [20785540]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 2843
Про supertype-subtype слышали?
11 сен 17, 08:06    [20785603]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
982183
"Множество таблиц2 - глупость несусветная.


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

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


А вот про таблицу связей можно подробнее?
11 сен 17, 17:14    [20787739]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
Ennor Tiegael
Про supertype-subtype слышали?

Описанный мной костыль и есть паттерн supertype-subtype, разве нет?
11 сен 17, 17:15    [20787743]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
registerers
Ennor Tiegael
Про supertype-subtype слышали?

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


Нет. В означенном паттерне нет никаких tablename
11 сен 17, 17:32    [20787798]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
Кот Матроскин
Нет. В означенном паттерне нет никаких tablename


Атрибут TableName в моём случае играет роль Type, суть одна. Это антипаттерн, так как смешиваются данные и метаданные. Другими словами, средствами РСУБД невозможно исключить ситуацию, когда в двух и более таблицах подтипа внешний ключ указывает на одну запись супертипа. В этом случае изменение типа приводит к нарушению ссылочной целостности
11 сен 17, 17:58    [20787882]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
SERG1257
Member

Откуда:
Сообщений: 2491
Заведите общего предка для продуктов с двумя (пока) полями id primary key, name unique
Наложите на ProductA ProductB FK reference на эту общую таблицу
Эта же таблица будет удобна для поиска (в нее можно напихать индексированных полей для быстрого поиска) по всем товарам.
11 сен 17, 18:24    [20787963]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
registerers
Это антипаттерн, так как смешиваются данные и метаданные.

Не более, чем при использовании суррогатного ключа в таблице. Может, суррогатный ключ - это тоже антипаттерн? :)
registerers
Другими словами, средствами РСУБД невозможно исключить ситуацию, когда в двух и более таблицах подтипа внешний ключ указывает на одну запись супертипа. В этом случае изменение типа приводит к нарушению ссылочной целостности

Тоже мне, бином Ньютона - включаете поле Type в ключ, накладываете на него соответствующие ограничения в каждой из subtype-таблиц.
11 сен 17, 18:28    [20787976]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

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


Вынести атрибуты товаров в универсальную структуру: атрибут-значение.
Делать по таблице на каждый вид товара -- это наверное самое тупое, что вообще только можно выдумать.
11 сен 17, 23:02    [20788454]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Bsplesk
Member

Откуда:
Сообщений: 30
На самом деле EAV, не так уж и плох, да много join, посмотрите magneto, с jsonb не так все радужно, как малюют, так как вероятно наборы справочников вам все равно придется хранить (дополнительные дубли), + при записи jsonb данные необходимо валидировать, это удобно делать при помощи схем (к примеру одна схема на несколько типов), но допустим json-schema сырая, до xml-schema ещё как до Китая. С динамической моделью данных при работе с jsonb/json-schema тоже не все гладко ... Да и при текущей реализации jsonb это больше одно поле = один объект, иначе замучаетесь разворачивать все таки до работы со сложными графами сущностей все очень сыро, правда в 10 обещают улучшить, но это завязка на конкретную СУБД хоть и открытую....
11 сен 17, 23:21    [20788481]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 43631

Bsplesk
да много join

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

Posted via ActualForum NNTP Server 1.5

12 сен 17, 01:13    [20788576]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
982183
Member

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

Там же и описываются громадные недостатки этого метода.
registerers
А вот про таблицу связей можно подробнее?

А связь номенклатуры и атрибутов вы хранить где думаете?
12 сен 17, 04:54    [20788633]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Незнайка.
Member [заблокирован]

Откуда:
Сообщений: 26
registerers
множество таблиц разных товаров, потому что набор свойств (атрибутов) у них разный

На каждый товар - отдельная таблица?
Кому и как такое могло в голову прийти?
12 сен 17, 07:23    [20788672]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
982183
Member

Откуда:
Сообщений: 917
На каждую группу товаров.
Технология "Flat tables" как было описано в ссылке выше :)
Вещь конечно узко специфичная. Я не сталкивался.
12 сен 17, 08:13    [20788716]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
982183
Member

Откуда:
Сообщений: 917
И тут уже оказывается всё обсасывалось.
17550595
12 сен 17, 08:17    [20788724]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1013
982183
https://zlob.in/2013/01/struktura-tablic-dlya-kataloga-tovarov-internet-magazina/

Я голосую за 6НФ. Почему-то по ссылке нет этого варианта. Вроде у Avito используется такой подход, но это не точно.
12 сен 17, 09:35    [20788958]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 2843
registerers
Ennor Tiegael
Про supertype-subtype слышали?

Описанный мной костыль и есть паттерн supertype-subtype, разве нет?
Вообще ничего общего.

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

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

На эту же таблицу будет ссылаться корзина. Только вот, зачем у вас корзина ссылается на заказы? Во всех магазинах, какие я видел, если товар лежит в корзине, значит заказ на него еще не существует, ммм? Корзину лучше сделать М:М связкой между Products и Customers, как у всех.
12 сен 17, 10:12    [20789085]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
tip78
Member

Откуда: Москва
Сообщений: 442
registerers
982183
Таблица связей (чаще всего групп связей)


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

гуглите "Нормальная Форма"
12 сен 17, 11:06    [20789231]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
Кот Матроскин
Может, суррогатный ключ - это тоже антипаттерн? :)

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

Кот Матроскин
включаете поле Type в ключ, накладываете на него соответствующие ограничения в каждой из subtype-таблиц

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

Кстати, если это не костыль, то напишите JOIN-запрос для такого кейса)))
13 сен 17, 15:03    [20792998]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
По поводу тезиса "делать по таблице на каждый вид товара - это самое тупое, что только можно придумать", отвечу сразу, чтоб закрыть этот вопрос. Есть такая штука, как компромисс между гибкостью и производительностью. Если гибкость не нужна, то юзаем Flat Tables, если нужна - EAV, NoSQL etc. И. кстати, кроме НФ есть ещё такое понятие как денормализация, которую как раз и применяют для оптимизации производительности.
13 сен 17, 15:13    [20793040]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
Dimitry Sibiryakov
Bsplesk
да много join

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

это как? выгребать все данные потаблично и джойнить на клиенте?? о_О
13 сен 17, 15:19    [20793056]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
982183
Там же и описываются громадные недостатки этого метода.
registerers
А вот про таблицу связей можно подробнее?

А связь номенклатуры и атрибутов вы хранить где думаете?

Не совсем понимаю, о чём вы. Вместо тысячи слов лучше нарисуйте пример диаграммы на draw.io
13 сен 17, 15:24    [20793073]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 43631

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

Нет: делать PIVOT на клиенте.

Posted via ActualForum NNTP Server 1.5

13 сен 17, 15:36    [20793119]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
registerers
Кот Матроскин
включаете поле Type в ключ, накладываете на него соответствующие ограничения в каждой из subtype-таблиц

Интересно, как вы себе представляете эти "соответствующие ограничения"?))

Крайне просто - ограничение значения константой.

registerers
Вот, например, физическая модель, из которой видно, что любая из subtype-таблиц может ссылаться на одну и ту же запись в supertype-таблице:
Картинка с другого сайта.

Тут есть Type в составе ключа Product?
13 сен 17, 15:40    [20793132]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин,

Cart и Order лучше бы отсадить, так как корзина это то, с чем работает пользователь, а заказ это то, с чем работает отдел продаж и доставки. Заказ может впоследствии отличаться от корзины.
13 сен 17, 15:56    [20793166]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
Ennor Tiegael
Вообще ничего общего.

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

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

Разве в моём примере не так?)))

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

Связь между заказами и товарами в корзине должна же быть в любом случае. Также должна быть связь между заказами и покупателями. В таком случае возникает избыточность и цикличность связей: товары в корзине связаны с покупателями непосредственно и через заказ.
Картинка с другого сайта.
13 сен 17, 15:59    [20793173]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Кот Матроскин,

Cart и Order лучше бы отсадить, так как корзина это то, с чем работает пользователь, а заказ это то, с чем работает отдел продаж и доставки. Заказ может впоследствии отличаться от корзины.

схема не моя, а моего оппонента :) но я, кстати, не разделяю идею "Cart и Order лучше бы отсадить".
Работают разные категории пользователей - ну и что? С таблицей контрагентов может работать десяток разных категорий - ее тоже надо бить на 10 разных таблиц? :)
Заказ может впоследствии отличаться от корзины - опять же, заказ может изменяться (и, следовательно, отличаться от предыдущего состояния) на разных этапах своего существования, и что?
13 сен 17, 16:14    [20793223]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
tip78
Member

Откуда: Москва
Сообщений: 442
Кот Матроскин
hVostt
Кот Матроскин,

Cart и Order лучше бы отсадить, так как корзина это то, с чем работает пользователь, а заказ это то, с чем работает отдел продаж и доставки. Заказ может впоследствии отличаться от корзины.

схема не моя, а моего оппонента :) но я, кстати, не разделяю идею "Cart и Order лучше бы отсадить".
Работают разные категории пользователей - ну и что? С таблицей контрагентов может работать десяток разных категорий - ее тоже надо бить на 10 разных таблиц? :)
Заказ может впоследствии отличаться от корзины - опять же, заказ может изменяться (и, следовательно, отличаться от предыдущего состояния) на разных этапах своего существования, и что?


согласен, проще флаг сменить: 1 = корзина; 2 = заказ
13 сен 17, 17:57    [20793592]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
Кот Матроскин
Тут есть Type в составе ключа Product?

Вы имели в виду что-то вроде этого?
Картинка с другого сайта.

Но тогда возникает вопрос - как обеспечить константность значений полей SubA.Type, SubB.Type, и как быть с суб-таблицами при удалении соответствующих типов?
13 сен 17, 18:54    [20793721]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

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

Ограничениями (check), я же сказал. У разных СУБД механизм отличается, но не сильно.
registerers
и как быть с суб-таблицами при удалении соответствующих типов?

Не понял. Вы хотите убить тип "ProductB", но при этом сохранить таблицу ProductB? А какой в этом физический смысл?
13 сен 17, 19:41    [20793844]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

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

Наоборот, я не хочу сохранять эту таблицу))) В том то и дело, что не существует механизма удалить таблицу автоматически и это нужно делать только в приложении
13 сен 17, 20:19    [20793913]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

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

Наоборот, я не хочу сохранять эту таблицу))) В том то и дело, что не существует механизма удалить таблицу автоматически и это нужно делать только в приложении

Не вижу проблем в пустой таблице (очиститься-то она у Вас очистится при ON DELETE CASCADE).
Да, в реляционной модели при очистке родительской таблицы подчиненные таблицы автоматом не дропаются - при удалении всех заказов таблица элементов заказов тоже не дропается, если такое поведение требуется - надо прописывать руками. Если Вы это считаете серьезным недостатком - ну да, РСУБД Вам подходят не очень.
13 сен 17, 20:55    [20793963]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
Кот Матроскин
registerers
пропущено...

Наоборот, я не хочу сохранять эту таблицу))) В том то и дело, что не существует механизма удалить таблицу автоматически и это нужно делать только в приложении

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

Вот! Что, собственно, и требовалось доказать. Всем спасибо за ответы!
13 сен 17, 22:31    [20794099]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
tip78
Member

Откуда: Москва
Сообщений: 442
registerers
Кот Матроскин
пропущено...

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

Вот! Что, собственно, и требовалось доказать. Всем спасибо за ответы!

не это, а то что ваша архитектура БД - дичь
14 сен 17, 00:35    [20794234]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 2843
registerers,

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

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

Ну и наконец, если пользователь захочет отправить содержимое корзины по нескольким адресам - как у Амазона, "Deliver to multiple addresses" - придется проделывать кучу дополнительных телодвижений.
14 сен 17, 06:48    [20794331]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
схема не моя, а моего оппонента :) но я, кстати, не разделяю идею "Cart и Order лучше бы отсадить".
Работают разные категории пользователей - ну и что? С таблицей контрагентов может работать десяток разных категорий - ее тоже надо бить на 10 разных таблиц? :)
Заказ может впоследствии отличаться от корзины - опять же, заказ может изменяться (и, следовательно, отличаться от предыдущего состояния) на разных этапах своего существования, и что?


Вот именно, что может изменяться. Поэтому надо разделять. Пользователь редактирует корзину, заказ редактировать не может. Да и циклы разные.
14 сен 17, 08:07    [20794391]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Ennor Tiegael
Ну и наконец, если пользователь захочет отправить содержимое корзины по нескольким адресам - как у Амазона, "Deliver to multiple addresses" - придется проделывать кучу дополнительных телодвижений.


Если корзина и заказ — разные таблицы и сущности, то сделать подобное не проблема
14 сен 17, 08:07    [20794393]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Кот Матроскин
схема не моя, а моего оппонента :) но я, кстати, не разделяю идею "Cart и Order лучше бы отсадить".
Работают разные категории пользователей - ну и что? С таблицей контрагентов может работать десяток разных категорий - ее тоже надо бить на 10 разных таблиц? :)
Заказ может впоследствии отличаться от корзины - опять же, заказ может изменяться (и, следовательно, отличаться от предыдущего состояния) на разных этапах своего существования, и что?


Вот именно, что может изменяться. Поэтому надо разделять. Пользователь редактирует корзину, заказ редактировать не может. Да и циклы разные.

Заказ тоже может изменяться и отличаться от самого себя на вчера - что и с чем Вы будете разделять в этом случае?

hVostt
Если корзина и заказ — разные таблицы и сущности, то сделать подобное не проблема

Если корзина и элементы заказа это одна таблица - то внезапно тоже (хотя я знаю мало интернет-магазинов, которые вместо того чтобы предложить в этом случае пользователю оформить несколько заказов, делают такую штуку).
14 сен 17, 11:04    [20794903]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
Заказ тоже может изменяться и отличаться от самого себя на вчера - что и с чем Вы будете разделять в этом случае?


Вопрос в том, кто его может изменить и область его ответственности. Про отличаться от самого себя, это про историю, решается тоже по-разному.


Кот Матроскин
Если корзина и элементы заказа это одна таблица - то внезапно тоже (хотя я знаю мало интернет-магазинов, которые вместо того чтобы предложить в этом случае пользователю оформить несколько заказов, делают такую штуку).


Глупо спорить с тем, что гвоздь можно забить микроскопом. Можно вообще всё на одной таблице сделать. А можно и на счётах всё посчитать.

Но поддерживать это будет трудоёмко и, соответственно, дорого.
14 сен 17, 11:29    [20795010]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Про отличаться от самого себя, это про историю, решается тоже по-разному.

Зачем тогда это приводить как аргумент за "надо разделять", если никакой причинно-следственной связи "может отличаться"->"надо разделять" нет?
hVostt
Но поддерживать это будет трудоёмко и, соответственно, дорого.

С чего бы? :)
Наоборот - не надо будет дублировать методы "добавить элемент в заказ", "добавить элемент в корзину", "удалить элемент из заказа", "удалить элемент из корзины", "рассчитать общую стоимость заказа", "рассчитать общую стоимость корзины", ....
14 сен 17, 11:37    [20795046]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
tip78
Member

Откуда: Москва
Сообщений: 442
любители хранить корзины отдельно, какую ценность для вас несёт первозданная корзина ДО кнопки "оформить заказ" ?
после звонка менеджера выяснится, что чего-то нет, что-то забыли доложить, что-то надо заменить
важны не эти изменения, а только ОПЛАЧЕННЫЙ ЗАКАЗ = транзакция: -товар +деньги
а зачем плодить "черновики"?
14 сен 17, 11:38    [20795051]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 43631

tip78
а зачем плодить "черновики"?

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

Posted via ActualForum NNTP Server 1.5

14 сен 17, 11:52    [20795104]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
tip78
registerers
пропущено...

Вот! Что, собственно, и требовалось доказать. Всем спасибо за ответы!

не это, а то что ваша архитектура БД - дичь

Это не "моя ахритектура", а доказательство того, что Flat table - это антипаттерн))
14 сен 17, 12:06    [20795154]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
982183
Member

Откуда:
Сообщений: 917
Скорее моветон.
14 сен 17, 12:13    [20795178]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
Ennor Tiegael
registerers,

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

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

Ну и наконец, если пользователь захочет отправить содержимое корзины по нескольким адресам - как у Амазона, "Deliver to multiple addresses" - придется проделывать кучу дополнительных телодвижений.

Где вы увидели "жесть"? Связь в корзине между продуктом и заказом появляется после его оформления. То есть поле Cart.OrderId может быть nullable, что является признаком того, что товар добавлен в корзину, но ещё не оформлен
14 сен 17, 12:20    [20795207]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

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

Бугога)) А по какому признаку вы собираетесь агрегировать товары в таблице? По времени добавления в корзину?)))
14 сен 17, 12:40    [20795277]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
982183
Скорее моветон.

Так а можете предложить что-то лучше?)
Например, как писалось выше, EAV не совсем уместен, когда видов товара, скажем 2-3, но много записей самих товаров. Поэтому Flat table здесь как бы больше подходит, но обладает своими недостатками, о которых я писал.
Ну, как более универсальный вариант - это хранение атрибутов товаров в новомодных хипстерских штучках вроде NoSQL
14 сен 17, 12:50    [20795321]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
982183
Member

Откуда:
Сообщений: 917
Это философия.
Есть варианты, конкретный выбор зависит от ситуации.
14 сен 17, 12:55    [20795341]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
tip78
Member

Откуда: Москва
Сообщений: 442
Dimitry Sibiryakov
tip78
а зачем плодить "черновики"?

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

"упадёт" она, только если вы её удалите
так вот не удаляйте.
и не придётся лепить кучу ненужных таблиц
14 сен 17, 13:11    [20795444]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
tip78
Member

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

Бугога)) А по какому признаку вы собираетесь агрегировать товары в таблице? По времени добавления в корзину?)))

по id, например
:рукалицо:
нормальную форму бегом гуглить, пока ваше понимание "таблиц" и "реляционности" не придёт в норму
14 сен 17, 13:16    [20795469]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
tip78
Dimitry Sibiryakov
пропущено...

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

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


Вы вообще в курсе о существовании такого понятия как нормальная форма и зачем это?))
14 сен 17, 13:31    [20795593]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
tip78
registerers
пропущено...

Бугога)) А по какому признаку вы собираетесь агрегировать товары в таблице? По времени добавления в корзину?)))

по id, например
:рукалицо:
нормальную форму бегом гуглить, пока ваше понимание "таблиц" и "реляционности" не придёт в норму

Вы же как раз и предлагаете денормализовать)))
14 сен 17, 13:32    [20795600]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

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

Ограничениями (check), я же сказал. У разных СУБД механизм отличается, но не сильно.

Интересно, а какие техники реализации существуют? Например, мне приходит в голову только определение в subtype-таблице поля с ненулевым дефолтным значением TypeId и убрать update/insert из грантов (конечно, если это PostgreSQL). Но это тоже пахнет костылём, ибо дефолтное значение - это часть DDL, т.е. метаинформация, а конкретное значение id supertype-таблицы - это данные.
Так что не так всё просто, как вы рисуете...
14 сен 17, 13:44    [20795688]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
tip78
Member

Откуда: Москва
Сообщений: 442
registerers
Вы вообще в курсе о существовании такого понятия как нормальная форма и зачем это?))

в профили заглядывайте иногда
вам бы тут не выёживаться надо, а всасывать каждую букву, коли за помощью пришли со своими дикими идеями
14 сен 17, 14:13    [20795858]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
tip78
registerers
Вы вообще в курсе о существовании такого понятия как нормальная форма и зачем это?))

в профили заглядывайте иногда
вам бы тут не выёживаться надо, а всасывать каждую букву, коли за помощью пришли со своими дикими идеями

Вот только давайте без обид и без снобизма, только по сути)) Эмоции часто вредят продуктивной дискуссии. А форумы, кстати, существуют не только для помощи, но и для обмена идеями. Бинго! Просто хочется разобраться в теоретических вопросах, думаю, не только одному мне это интересно. А теперь по сути объясните, почему то, что вы предлагаете не является денормализацией?
14 сен 17, 14:24    [20795916]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
tip78
Member

Откуда: Москва
Сообщений: 442
registerers
tip78
пропущено...

в профили заглядывайте иногда
вам бы тут не выёживаться надо, а всасывать каждую букву, коли за помощью пришли со своими дикими идеями

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


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

2. а теперь по сути:
/* ЗАКАЗЫ
история заказов через статусы
статусы/товары берутся по order_id в order_statuses/_products
клиенты/менеджеры/курьеры и прочие люди - ВСЕ в таблице users
*/

CREATE TABLE orders(
id bigserial PRIMARY KEY,       -- ID заказа, по которому привязываются товары/статусы/склад/курьер/итд
uid int,                        -- чей заказ
address_id int default 0,       -- ID из addresses (у клиента их может быть несколько)
delivery_id int default 0,      -- ID из delivery_methods
payment_id int default 0,       -- ID из payment_methods
comment text default '',        -- произвольная запись от клиента
summ int default 0,             -- финальная общая сумма заказа фиксируется (при оплате) навсегда, потому что через неделю у товаров будут уже другие цены
added timestamptz DEFAULT NOW()
);

CREATE INDEX ON orders (uid);
CREATE INDEX ON orders USING brin(added);


-- статусы заказа

CREATE TABLE order_statuses(
order_id int,                   -- ID заказа
uid int,                        -- чей статус (например, "собран" = uid складовщика, а "передан курьеру/доставлен" = uid курьера)
status smallint default 1,      -- статус заказа: 1 корзина; 2 оформлен; 4 подтверждён; 8 отказ; 16 собран; 32 передан курьеру; 64 доставлен; 128 оплачен;
added timestamptz default now() -- когда какой статус случился
);

CREATE INDEX ON order_statuses (order_id);
CREATE INDEX ON order_statuses (status);


-- товары в заказе

CREATE TABLE order_products(
order_id int PRIMARY KEY,       -- ID заказа
pid int                         -- ID товара
);

CREATE INDEX ON order_products (order_id);
CREATE INDEX ON order_products (pid);
14 сен 17, 19:09    [20796966]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
tip78
1. МЫ тут не ради ваших "квадратных велосипедов идей". Зачем нам деградировать?? В этой теме ВАМ вправляют мозги, а вы наполняетесь счастьем.

Да не бойтесь вы, мышление ещё никогда никого не привело к деградации)) Вот и вправьте мне мозги, ответив на мой вопрос топика, а не уходя от него ;-)

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

Поэтому я и говорю, читайте внимательно первый пост и последующие. Под "ТУТ" подразумевалась конкретная задача, которая часто встречается, а EAV - всего лишь один из способов решения задачи. Собственно, целью сабжа было прояснить, какие вообще подходы к решению задачи существуют и насколько они эффективны. Не зря же придумали документно-ориентированные СУБД. Понимаю, что тема холиварная, но давайте обмениваться аргументами, а не эмоциями!

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

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

tip78
2. а теперь по сути:

Вот так бы и сразу)) Спасибо за ваш SQL-код, вижу, что вы старались. Но это почти оффтоп. Корзина в поставленной задаче не главное, логика её работы - отдельная тема. То кому-то что-то не понравилось и понеслось... Я вообще пример с магазином придумал потому что он многим знаком. Суть же задачи, которую я ставил состоит в том, возможно ли в денормализованных архитектурах БД выдержать условия однозначности и непротиворечивости реляционных связей? В случае Flat table (type-supertype), это невозможно, что было показано выше. Представьте, у вас есть родительская (supertype) таблица и две дочерние (subtype). Для определения того, с какой из дочерних таблиц заджойнить родительскую, нужно сначала проверить в ней значение поля Type. Вот лучше этот один запрос напишите, тогда и поговорим о реляционной алгебре ;-)
14 сен 17, 21:11    [20797249]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
registerers
Не зря же придумали документно-ориентированные СУБД.


Каждый день что-то придумывают.

И каждый день некоторые люди узнают, что земля оказывается круглая, но предлагают обсудить также идеи насчёт того, что она вообще-то может быть плоской или квадратной.
14 сен 17, 21:49    [20797328]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
registerers
Суть же задачи, которую я ставил состоит в том, возможно ли в денормализованных архитектурах БД выдержать условия однозначности и непротиворечивости реляционных связей? В случае Flat table (type-supertype), это невозможно, что было показано выше.

Правда? И в каком посте?
registerers
Представьте, у вас есть родительская (supertype) таблица и две дочерние (subtype). Для определения того, с какой из дочерних таблиц заджойнить родительскую, нужно сначала проверить в ней значение поля Type.

Нет, не нужно.
Ну почитайте что-нибудь про subtype-supertype, в самом деле - как с ним работают, etc. Вы постоянно выдвигаете какие-то нелепые тезисы про него - то дублирования записей нельзя избежать, теперь вот перед join-ом что-то проверять надо...
14 сен 17, 22:13    [20797375]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
registerers
Member

Откуда:
Сообщений: 47
Кот Матроскин
Вы постоянно выдвигаете какие-то нелепые тезисы про него - то дублирования записей нельзя избежать, теперь вот перед join-ом что-то проверять надо...

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

Окей, если мой вопрос по джойнам "нелеп", как вы выведете список товаров всех типов?)))
SELECT * FROM supertype
JOIN ??? ON ???.id = supertype.id
14 сен 17, 23:20    [20797468]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 2843
hVostt
Ennor Tiegael
Ну и наконец, если пользователь захочет отправить содержимое корзины по нескольким адресам - как у Амазона, "Deliver to multiple addresses" - придется проделывать кучу дополнительных телодвижений.

Если корзина и заказ — разные таблицы и сущности, то сделать подобное не проблема
Ничто не проблема. Вопрос, зачем делать, если сейчас делать не нужно, а потом возможно придется переделывать?

registerers,

Я кажется понял, в чем нестыковка. Вы называете "корзиной" элементы заказа. Не советую так делать, имхо лучше сделать отдельную таблицу OrderItems, и в нее копировать записи из корзины (с одновременным удалением их из оной). Это разные сущности, с весьма разнящимися атрибутами.
15 сен 17, 04:52    [20797588]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Ennor Tiegael
Ничто не проблема. Вопрос, зачем делать, если сейчас делать не нужно, а потом возможно придется переделывать?


Ну что поделаешь, не каждому дано думать на пару шагов вперёд. Переделывать всегда сложнее, чем заложить изначально. Надо уменьшать эти издержки по возможности.
15 сен 17, 08:49    [20797735]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
registerers
Кот Матроскин
Вы постоянно выдвигаете какие-то нелепые тезисы про него - то дублирования записей нельзя избежать, теперь вот перед join-ом что-то проверять надо...

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

Кот Матроскин
Тоже мне, бином Ньютона - включаете поле Type в ключ, накладываете на него соответствующие ограничения в каждой из subtype-таблиц.

registerers
Окей, если мой вопрос по джойнам "нелеп", как вы выведете список товаров всех типов?)))
SELECT * FROM supertype
JOIN ??? ON ???.id = supertype.id


Наводящее уточнение - у разных типов существенно разные поля (иначе паттерн был бы не нужен). Вы хотите видеть в списке все возможные поля всех типов для каждого товара? Или только общие для всех типов поля?
После ответа на это уточнение запрос имхо становится вполне очевидным
15 сен 17, 09:23    [20797799]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Ennor Tiegael
Ничто не проблема. Вопрос, зачем делать, если сейчас делать не нужно, а потом возможно придется переделывать?


Ну что поделаешь, не каждому дано думать на пару шагов вперёд. Переделывать всегда сложнее, чем заложить изначально. Надо уменьшать эти издержки по возможности.

Таки расскажите, какой конкретно кейс Вы отдельной таблицей под корзину "закладываете изначально", а в случае единой таблицы "придется переделывать"?
15 сен 17, 09:28    [20797806]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
Таки расскажите, какой конкретно кейс Вы отдельной таблицей под корзину "закладываете изначально", а в случае единой таблицы "придется переделывать"?


Мне ещё раз повторить, что корзина это то, с чем работает пользователь, а заказ это то с чем работают сотрудники магазина?

В чём проблема-то, думать головой используя банальную логику, принципы разработки, и закладывать это изначально, а не потом когда-нибудь?
15 сен 17, 09:52    [20797847]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 2843
Кот Матроскин,

Вы, наверное, меня имели в виду.

Моя логика в том, что корзина - сущность временного назначения, и данные там лежат только до тех пор, пока не сформирован(ы) заказ(ы). Семантически она не тождественна позициям заказа - там могут быть какие-то столбцы, неактуальные для позиций заказа, и не быть многих, которые актуальны. Например, все что связано с выбором склада, если таковых больше одного. Или такой вариант: юзер берет 5 экземпляров какой-то позиции, 3 берутся с одного склада, а оставшиеся 2 - с другого. Зачем это в корзине? А когда юзер передумает и уменьшит количество, опять обтанцовывать кактус кругом?

Почему мне не нравится идея одной таблицы вместо двух: если / когда пользователь начнет разносить содержимое корзины на несколько заказов, придется делать дополнительные телодвижения в виде апдейта поля OrderId, причем нелинейного - какая-то часть позиций остается в дефолтном заказе, остальные разъезжаются по новым. Учитывая, что я еще ни разу не видел интернет-магазина, где разбивка по заказам сохранялась бы до оплаты, не думаю, что это сильно востребовано рынком. Конечно, если средний заказ состоит из сотен позиций, возможно это и имеет смысл, но сколько таких магазинов?

Ну и я до сих пор не увидел рациональной аргументации, зачем пользователю иметь OrderId на стадии наполнения корзины. Вы же понимаете, что столбцы на страницах занимают место, и каждое обращение к корзине будет этот столбец с диска поднимать, даже если он не включен в селект. Ну и размер таблицы в этом случае будет совсем не копеечный.
15 сен 17, 09:55    [20797863]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин,

В большинстве случаев у пользователя всего одна корзина. В определённый момент пользователь делает заказ, корзина «очищается», а заказ остаётся. В это время пользователь может опять накидывать товары в корзину.

Далее, разработчики могут предложить функцию мульти-корзины. Самое банальное: отложенные товары в отдельной корзине. Потом можно приделать несколько корзин, чтобы пользователь мог разделить покупки, куплю сейчас, куплю через неделю, куплю когда-нибудь, это себе, это жене.. и т.д. Корзина это чисто пользовательская концепция. Что здесь непонятного?
15 сен 17, 10:00    [20797876]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Ennor Tiegael
Ну и я до сих пор не увидел рациональной аргументации, зачем пользователю иметь OrderId на стадии наполнения корзины. Вы же понимаете, что столбцы на страницах занимают место, и каждое обращение к корзине будет этот столбец с диска поднимать, даже если он не включен в селект. Ну и размер таблицы в этом случае будет совсем не копеечный.


Дело даже не в этом. Само наличие заказа подразумевает начало некоего workflow, появление нового заказа в системе это событие. А работа с корзиной это совершенно отдельная история. С корзиной могут быть связаны совершенно другие процессы.
15 сен 17, 10:02    [20797887]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Кот Матроскин
Таки расскажите, какой конкретно кейс Вы отдельной таблицей под корзину "закладываете изначально", а в случае единой таблицы "придется переделывать"?


Мне ещё раз повторить, что корзина это то, с чем работает пользователь, а заказ это то с чем работают сотрудники магазина?

Ну запретить повторить я Вам не могу - свободная страна, все такое :)
Но имхо желательно, чтобы аргументы были как-то связаны с защищаемой позицией.
Вы начали говорить про "переделывать всегда сложнее". Так что и зачем нужно переделывать? Вы в рамках одной таблицы никак, просто совсем никак не можете реализовать "корзина это то, с чем работает пользователь, а заказ это то с чем работают сотрудники магазина"?
15 сен 17, 10:12    [20797910]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
Ennor Tiegael
Кот Матроскин,

Вы, наверное, меня имели в виду.

Нет, не совсем :)
Вы не произносите трескучих фраз "поддерживать дорого", "надо думать изначально" и т.д.

Ennor Tiegael
Почему мне не нравится идея одной таблицы вместо двух: если / когда пользователь начнет разносить содержимое корзины на несколько заказов, придется делать дополнительные телодвижения в виде апдейта поля OrderId, причем нелинейного - какая-то часть позиций остается в дефолтном заказе, остальные разъезжаются по новым.

В смысле - какие дополнительные телодвижения? Что в том что в другом случае у Вас есть некое множество товаров, части этого множества Вам надо разложить на N заказов. Где именно тут дополнительные телодвижения?
Наоборот, как я уже говорил, у Вас в системе все равно уже есть API "переложить часть заказа в новый заказ", и Вам не надо делать новую процедуру "переложить часть корзины в новый заказ"
Ennor Tiegael

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

У Вас будет CustomerID вместо этого - который точно так же занимает место, поднимается с диска и т.п.
15 сен 17, 10:26    [20797959]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Далее, разработчики могут предложить функцию мульти-корзины. Самое банальное: отложенные товары в отдельной корзине. Потом можно приделать несколько корзин, чтобы пользователь мог разделить покупки, куплю сейчас, куплю через неделю, куплю когда-нибудь, это себе, это жене.. и т.д. Корзина это чисто пользовательская концепция. Что здесь непонятного?

Что именно из перечисленного у Вас не получается в случае единой таблицы?
15 сен 17, 10:32    [20797979]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
Вы начали говорить про "переделывать всегда сложнее". Так что и зачем нужно переделывать? Вы в рамках одной таблицы никак, просто совсем никак не можете реализовать "корзина это то, с чем работает пользователь, а заказ это то с чем работают сотрудники магазина"?


Я не говорил «никак», в конце концов и микроскопом можно гвозди забивать. Вы мне упорно хотите доказать, что это можно сделать, а я с этим даже спорить не собираюсь. Если вам удобно, можете и кулаком забивать, дело сугубо ваше.

Корзина и заказ — разные вещи по сути и по логике. Адекватный разработчик в БД для разных вещей смоделирует отдельные таблицы. С чём вы пытаетесь спорить я до сих пор не пойму.
15 сен 17, 10:55    [20798049]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
Что именно из перечисленного у Вас не получается в случае единой таблицы?


Зачем вы приплели сюда понятие «получится»? Удобно и комфортно работать с этим, если для разных по смыслу и функциональности понятий будут выделены отдельные сущности и таблицы. Не удобно и не комфортно, трудносопровождаемо это будет сделать на одной, но если человек не может пользоваться мозгом, то ему нечего делать в разработке, пусть идёт лопатой машет.
15 сен 17, 10:57    [20798055]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 2843
Кот Матроскин
у Вас в системе все равно уже есть API "переложить часть заказа в новый заказ"
Нет у меня такого, зачем он мне? Как юзер по заказам разбил, так и сохраню. Даже если какой-то позиции не было в корзине - пофиг, в пост-контроллер пришло, значит надо.
Кот Матроскин
У Вас будет CustomerID вместо этого - который точно так же занимает место, поднимается с диска и т.п.
Этот там нужен - по нему фильтрация идет. Или у вас все юзеры видят все корзины? Вы, конечно, можете сказать "а до кастомеров можно через ордеры достучаться", но если, как предполагал ТС, изначально писать в это поле null...

В общем, бритву Оккама вы не убедили. Насчет ТС - не в курсе, я это тут пишу, скорее, для тех, кто потом найдет этот топик и будет пытаться сделать по аналогии.
15 сен 17, 11:02    [20798075]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Кот Матроскин
Что именно из перечисленного у Вас не получается в случае единой таблицы?


Зачем вы приплели сюда понятие «получится»?

Потому что Вы приплели "переделывать". Переделывают что-то тогда, когда некую дополнительную функциональность реализовать либо не получается совсем, либо получается очень сложно. Так что же это за функциональность?
hVostt
Удобно и комфортно работать с этим, если для разных по смыслу и функциональности понятий будут выделены отдельные сущности и таблицы.

Да-да, как в соседней ветке - таблица Girl, таблица Man
15 сен 17, 11:09    [20798110]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
Ennor Tiegael
Кот Матроскин
у Вас в системе все равно уже есть API "переложить часть заказа в новый заказ"
Нет у меня такого, зачем он мне? Как юзер по заказам разбил, так и сохраню. Даже если какой-то позиции не было в корзине - пофиг, в пост-контроллер пришло, значит надо.

А вот у меня есть - потому что "отправить часть заказа, которую собрали" это офигенно частый кейс.
Ennor Tiegael
Кот Матроскин
У Вас будет CustomerID вместо этого - который точно так же занимает место, поднимается с диска и т.п.
Этот там нужен - по нему фильтрация идет. Или у вас все юзеры видят все корзины? Вы, конечно, можете сказать "а до кастомеров можно через ордеры достучаться"

Разумеется можно - поэтому никакого "лишнего" места не тратится, одно поле заменяется другим.
15 сен 17, 11:14    [20798138]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
Потому что Вы приплели "переделывать". Переделывают что-то тогда, когда некую дополнительную функциональность реализовать либо не получается совсем, либо получается очень сложно. Так что же это за функциональность?


Например, хранение истории корзины и заказов. Заказы могут меняться, переукомплектовываться, разбиваться, сливаться, корзина в истории нет. Мульти-корзина, всяческие программы лояльности, и т.д.
15 сен 17, 11:45    [20798276]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
hVostt
Удобно и комфортно работать с этим, если для разных по смыслу и функциональности понятий будут выделены отдельные сущности и таблицы.

Да-да, как в соседней ветке - таблица Girl, таблица Man


Гендер это характеристика. А корзина или заказ -- нет.
15 сен 17, 11:45    [20798280]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Кот Матроскин
Потому что Вы приплели "переделывать". Переделывают что-то тогда, когда некую дополнительную функциональность реализовать либо не получается совсем, либо получается очень сложно. Так что же это за функциональность?


Например, хранение истории корзины и заказов. Заказы могут меняться, переукомплектовываться, разбиваться, сливаться, корзина в истории нет. Мульти-корзина, всяческие программы лояльности, и т.д.


Ээ... и что в этом сложного? манипуляции с заказом в статусе "корзина" не создают следов
в "исторических" таблицах, с заказами в остальных статусах - создают.
15 сен 17, 12:14    [20798407]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Кот Матроскин
автор
для разных по смыслу и функциональности понятий будут выделены отдельные сущности и таблицы


Да-да, как в соседней ветке - таблица Girl, таблица Man


Гендер это характеристика. А корзина или заказ -- нет.

Начинаете изобретать определение на ходу :)
раньше было "разных по смыслу и функциональности". Man и Girl - вполне себе разные по смыслу и уж тем более по функциональности :)
А "характеристика" или "не характеристика" - это вообще зависит не от самого понятия, а от модели, скажу по секрету ;) В каких-то моделях - характеристика, в каких-то - ключевое различие.
15 сен 17, 12:20    [20798436]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
Ээ... и что в этом сложного? манипуляции с заказом в статусе "корзина" не создают следов
в "исторических" таблицах, с заказами в остальных статусах - создают.


Заказ в статусе «корзина»? Лан, проехали. Бессмысленный спор.
15 сен 17, 12:20    [20798437]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
Начинаете изобретать определение на ходу :)
раньше было "разных по смыслу и функциональности". Man и Girl - вполне себе разные по смыслу и уж тем более по функциональности :)
А "характеристика" или "не характеристика" - это вообще зависит не от самого понятия, а от модели, скажу по секрету ;) В каких-то моделях - характеристика, в каких-то - ключевое различие.


Какие определения? Есть субъект «участник», у него есть характеристика «пол» — это атрибут субъекта. Два субъекта взаимодействуют друг с другом.

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

В общем понятно всё с вашей аргементацией.
15 сен 17, 12:25    [20798461]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Кот Матроскин
Ээ... и что в этом сложного? манипуляции с заказом в статусе "корзина" не создают следов
в "исторических" таблицах, с заказами в остальных статусах - создают.


Заказ в статусе «корзина»? Лан, проехали. Бессмысленный спор.

Если оперировать демагогическими штампами типа "надо думать головой", "придется переделывать" и т.п. - конечно бессмысленный. А если обсуждать конкретные объективные вещи типа сложности реализации той или иной фичи - вполне себе осмысленный правда, очень невыгодный для некоторых участников
15 сен 17, 12:27    [20798470]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
и для заказа абсолютно параллельно, была ли какая-то корзина или нет. Для корзины может быть сформирован заказ, на основе позиций в корзине, при чём не обязательно, что в заказ попадут все позиции из корзины, или в заказ не будут добавлены позиции при уточнении по телефону.

Как это все связано с вопросом "одна таблица или две"? :)
В случае одной таблицы Вы будете мучиться месяц, разобьете пару клавиатур и выдерете остатки волос, но так и сможете придумать, как реализовать "не обязательно, что в заказ попадут все позиции из корзины"?
15 сен 17, 12:33    [20798487]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
Если оперировать демагогическими штампами типа "надо думать головой", "придется переделывать" и т.п. - конечно бессмысленный. А если обсуждать конкретные объективные вещи типа сложности реализации той или иной фичи - вполне себе осмысленный правда, очень невыгодный для некоторых участников


Был интернет-магазин. Потом открылись бутики, заказы по телефону, оптовые продажи, торговля с юр. лицами — на кой хрен упала тут корзина? Корзина это лишь концепция пользователя интернет-магазина, один из многочисленных источников формирования заказа.

Думать головой и на пару шагов вперёд уже не модно? Апологеты херак-херак и в продакшен занимают нишу разработчиков? Не думаю.
15 сен 17, 12:33    [20798490]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
Как это все связано с вопросом "одна таблица или две"? :)
В случае одной таблицы Вы будете мучиться месяц, разобьете пару клавиатур и выдерете остатки волос, но так и сможете придумать, как реализовать "не обязательно, что в заказ попадут все позиции из корзины"?


Связано напрямую. Вы либо с самого начала понимаете устройство модели, либо не понимаете и тулите заказ и корзину в одну таблицу со смешным статусом «корзина». Даже джуниору это простительно лишь с натяжкой.
15 сен 17, 12:35    [20798498]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Кот Матроскин
Если оперировать демагогическими штампами типа "надо думать головой", "придется переделывать" и т.п. - конечно бессмысленный. А если обсуждать конкретные объективные вещи типа сложности реализации той или иной фичи - вполне себе осмысленный правда, очень невыгодный для некоторых участников


Был интернет-магазин. Потом открылись бутики, заказы по телефону, оптовые продажи, торговля с юр. лицами — на кой хрен упала тут корзина? Корзина это лишь концепция пользователя интернет-магазина, один из многочисленных источников формирования заказа.

И что? Наличие корзин в той же таблице, что и заказы запрещает создавать заказы без корзин? Нет, не запрещает и не мешает, это Вас кто-то обманул, а Вы не попытались "подумать головой и на два шага вперед" (с)
15 сен 17, 12:39    [20798516]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Кот Матроскин
Как это все связано с вопросом "одна таблица или две"? :)
В случае одной таблицы Вы будете мучиться месяц, разобьете пару клавиатур и выдерете остатки волос, но так и сможете придумать, как реализовать "не обязательно, что в заказ попадут все позиции из корзины"?


Связано напрямую. Вы либо с самого начала понимаете устройство модели, либо не понимаете и тулите заказ и корзину в одну таблицу со смешным статусом «корзина».

Я с самого начала понимаю устройство модели и храню заказы и корзины в одной таблице :)
И да, задача "не обязательно, что в заказ попадут все позиции из корзины", "история для заказов" и т.п. не вызывают у меня животного ужаса "Это ж ужасно сложно, надо все переделывать!", как у Вас :)
15 сен 17, 12:49    [20798542]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
И что? Наличие корзин в той же таблице, что и заказы запрещает создавать заказы без корзин? Нет, не запрещает и не мешает, это Вас кто-то обманул, а Вы не попытались "подумать головой и на два шага вперед" (с)


Ну что ж, вижу началась глупая и бессмысленная демагогия. Никто не может вам запретить делать плохо, максимум могут уволить.

Кот Матроскин
Я с самого начала понимаю устройство модели и храню заказы и корзины в одной таблице :)


Вы не понимаете бизнес-модель и разницу в понятиях.

Кот Матроскин
И да, задача "не обязательно, что в заказ попадут все позиции из корзины", "история для заказов" и т.п. не вызывают у меня животного ужаса "Это ж ужасно сложно, надо все переделывать!", как у Вас :)


Животной ужас? О, вы хотите поговорить об этом?
15 сен 17, 12:53    [20798550]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Ну что ж, вижу началась глупая и бессмысленная демагогия.

Глупая и бессмысленная демагогия началась гораздо раньше - с утверждений "Все придется переделывать!"

hVostt
Кот Матроскин
И да, задача "не обязательно, что в заказ попадут все позиции из корзины", "история для заказов" и т.п. не вызывают у меня животного ужаса "Это ж ужасно сложно, надо все переделывать!", как у Вас :)


Животной ужас? О, вы хотите поговорить об этом?

Да я вот сегодня весь день пытаюсь :) И все Ваши примеры "необычайно сложных задач" вызывают пока усмешку - напугать как-то пока никак у Вас не получается.
15 сен 17, 13:06    [20798608]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
tip78
Member

Откуда: Москва
Сообщений: 442
Ennor Tiegael
Кот Матроскин,

Вы, наверное, меня имели в виду.

Моя логика в том, что корзина - сущность временного назначения, и данные там лежат только до тех пор, пока не сформирован(ы) заказ(ы). Семантически она не тождественна позициям заказа - там могут быть какие-то столбцы, неактуальные для позиций заказа, и не быть многих, которые актуальны. Например, все что связано с выбором склада, если таковых больше одного. Или такой вариант: юзер берет 5 экземпляров какой-то позиции, 3 берутся с одного склада, а оставшиеся 2 - с другого. Зачем это в корзине? А когда юзер передумает и уменьшит количество, опять обтанцовывать кактус кругом?

не понял я эту логику...
автор
3 берутся с одного склада, а оставшиеся 2 - с другого

это вообще к товарам относится, причём тут корзина?
есть таблица/jsonb, где товар привязывается ко складам (один товар может быть на нескольких)

Почему мне не нравится идея одной таблицы вместо двух: если / когда пользователь начнет разносить содержимое корзины на несколько заказов, придется делать дополнительные телодвижения в виде апдейта поля OrderId, причем нелинейного - какая-то часть позиций остается в дефолтном заказе, остальные разъезжаются по новым. Учитывая, что я еще ни разу не видел интернет-магазина, где разбивка по заказам сохранялась бы до оплаты, не думаю, что это сильно востребовано рынком. Конечно, если средний заказ состоит из сотен позиций, возможно это и имеет смысл, но сколько таких магазинов?

просто создаётся новый заказ (корзина)
в код надо будет добавить параметр "активная корзина" и возможность иметь несколько заказов одновременно

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

чтобы товар попадал в его корзину, а не в чужую
а ещё когда UID нет (авторизации не было), тоже надо как-то товар ловить...
15 сен 17, 13:07    [20798614]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
tip78
Member

Откуда: Москва
Сообщений: 442
hVostt
Ennor Tiegael
Ну и я до сих пор не увидел рациональной аргументации, зачем пользователю иметь OrderId на стадии наполнения корзины. Вы же понимаете, что столбцы на страницах занимают место, и каждое обращение к корзине будет этот столбец с диска поднимать, даже если он не включен в селект. Ну и размер таблицы в этом случае будет совсем не копеечный.


Дело даже не в этом. Само наличие заказа подразумевает начало некоего workflow, появление нового заказа в системе это событие. А работа с корзиной это совершенно отдельная история. С корзиной могут быть связаны совершенно другие процессы.

какие?
15 сен 17, 13:08    [20798619]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
tip78
Member

Откуда: Москва
Сообщений: 442
hVostt
Кот Матроскин
Потому что Вы приплели "переделывать". Переделывают что-то тогда, когда некую дополнительную функциональность реализовать либо не получается совсем, либо получается очень сложно. Так что же это за функциональность?


Например, хранение истории корзины и заказов. Заказы могут меняться, переукомплектовываться, разбиваться, сливаться, корзина в истории нет. Мульти-корзина, всяческие программы лояльности, и т.д.

для этого статусы есть, как тут 20796966
и вообще "история заказа" это другая сущность (если она вам действительно нужна подробная), а не корзина + заказ
15 сен 17, 13:15    [20798643]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
Глупая и бессмысленная демагогия началась гораздо раньше - с утверждений "Все придется переделывать!"


Ну так и где ваши шикарные аргументы? Не увидел ни одного, кроме демагогии.


Кот Матроскин
Да я вот сегодня весь день пытаюсь :) И все Ваши примеры "необычайно сложных задач" вызывают пока усмешку - напугать как-то пока никак у Вас не получается.


У меня не было и в мыслях вас пугать. Но вы держитесь, а то мало ли что :)
15 сен 17, 13:17    [20798653]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
tip78
какие?


Что какие? Заказ сам себя сформирует, проведёт и проверит оплату, укомплектуется, и сам себя передаст в службу доставки? Где сам себя доставит и проконтролирует?
15 сен 17, 13:19    [20798658]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
tip78
для этого статусы есть, как тут 20796966
и вообще "история заказа" это другая сущность (если она вам действительно нужна подробная), а не корзина + заказ


Корзина не является заказом. Это не статус заказа. Не согласны?
15 сен 17, 13:20    [20798662]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 2843
Кот Матроскин
Ennor Tiegael
пропущено...
Нет у меня такого, зачем он мне? Как юзер по заказам разбил, так и сохраню. Даже если какой-то позиции не было в корзине - пофиг, в пост-контроллер пришло, значит надо.

А вот у меня есть - потому что "отправить часть заказа, которую собрали" это офигенно частый кейс.
Т.е. если у вас это есть, потому что вы решили не дробить заказы по адресам доставки, значит и у всех остальных так же должно быть? Понятненько.
15 сен 17, 13:22    [20798672]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Кот Матроскин
Глупая и бессмысленная демагогия началась гораздо раньше - с утверждений "Все придется переделывать!"


Ну так и где ваши шикарные аргументы? Не увидел ни одного, кроме демагогии.

Мои шикарные аргументы в защиту Вашего утверждения "все придется переделывать"? Хм.
15 сен 17, 13:24    [20798678]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
tip78
status smallint default 1,      -- статус заказа: 1 корзина; 2 оформлен; 4 подтверждён; 8 отказ; 16 собран; 32 передан курьеру; 64 доставлен; 128 оплачен;


Ну ясно. Студенты, не имеющие ни грамма реального опыта, балуются с флагами.
15 сен 17, 13:25    [20798682]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
Мои шикарные аргументы в защиту Вашего утверждения "все придется переделывать"? Хм.


Знатный вы фантазёр. Я не нашёл в своих утверждениях подобных слов.
15 сен 17, 13:27    [20798683]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 2843
Кот Матроскин
Ennor Tiegael
пропущено...
Этот там нужен - по нему фильтрация идет. Или у вас все юзеры видят все корзины? Вы, конечно, можете сказать "а до кастомеров можно через ордеры достучаться"

Разумеется можно - поэтому никакого "лишнего" места не тратится, одно поле заменяется другим.
В большинстве магазинов аноним может зайти и начать собирать корзину до авторизации. Будете в БД анонимный заказ сохранять? И отличаете их потом, наверное, как-то друг от друга?
15 сен 17, 13:27    [20798684]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Ennor Tiegael
В большинстве магазинов аноним может зайти и начать собирать корзину до авторизации. Будете в БД анонимный заказ сохранять? И отличаете их потом, наверное, как-то друг от друга?


Дык это.. у заказа будет статус «корзина» и «аноним»

Мда.
15 сен 17, 13:28    [20798687]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
Ennor Tiegael
Кот Матроскин
пропущено...

А вот у меня есть - потому что "отправить часть заказа, которую собрали" это офигенно частый кейс.
Т.е. если у вас это есть, потому что вы решили не дробить заказы по адресам доставки, значит и у всех остальных так же должно быть? Понятненько.

Я вообще-то привел другой кейс.
15 сен 17, 13:29    [20798691]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 2843
Кот Матроскин
Ennor Tiegael
пропущено...
Т.е. если у вас это есть, потому что вы решили не дробить заказы по адресам доставки, значит и у всех остальных так же должно быть? Понятненько.

Я вообще-то привел другой кейс.
Круто. А в моей аргументации это был один из ключевых аспектов, т.к. если бизнес решит, что ему никогда не понадобится мультишиппинг, то много какая ересь может оказаться вполне жизнеспособной.
15 сен 17, 13:35    [20798704]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
Ennor Tiegael
Кот Матроскин
пропущено...

Разумеется можно - поэтому никакого "лишнего" места не тратится, одно поле заменяется другим.
В большинстве магазинов аноним может зайти и начать собирать корзину до авторизации. Будете в БД анонимный заказ сохранять? И отличаете их потом, наверное, как-то друг от друга?

Конечно - анонимного пользователя с идентификацией по кукам и для него обычную корзину.
Я еще раз повторяю - точно так же Вам придется сохранить анонимного пользователя
для случая "корзина в отдельной таблице", вся разница - в том что у Вас будет CustomerID, а не OrderID.
15 сен 17, 13:36    [20798709]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
hVostt
Member

Откуда:
Сообщений: 11352
Кот Матроскин
для случая "корзина в отдельной таблице", вся разница - в том что у Вас будет CustomerID, а не OrderID.


OrderID в корзине вообще не нужен. На одну корзину может быть создано несколько заказов, а CustomerId нужен всегда.
15 сен 17, 13:38    [20798717]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 2843
tip78
Ennor Tiegael
Ну и я до сих пор не увидел рациональной аргументации, зачем пользователю иметь OrderId на стадии наполнения корзины. Вы же понимаете, что столбцы на страницах занимают место, и каждое обращение к корзине будет этот столбец с диска поднимать, даже если он не включен в селект. Ну и размер таблицы в этом случае будет совсем не копеечный.

чтобы товар попадал в его корзину, а не в чужую
а ещё когда UID нет (авторизации не было), тоже надо как-то товар ловить...
В большинстве магазинов аноним может зайти и начать собирать корзину до авторизации. Будете в БД анонимный заказ сохранять? И отличаете их потом, наверное, как-то друг от друга?
15 сен 17, 13:40    [20798724]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
Ennor Tiegael
Кот Матроскин
пропущено...

Я вообще-то привел другой кейс.
Круто. А в моей аргументации это был один из ключевых аспектов, т.к. если бизнес решит, что ему никогда не понадобится мультишиппинг, то много какая ересь может оказаться вполне жизнеспособной.


Я сказал что нет проблем сделать мультишиппинг в концепции "одна таблица", наоборот, будет выигрыш за счет того что не придется второй раз реализовывать фичу. Вы ответили "А мне и так не придется - у меня первой фичи нет!". Ну и кто тут должен говорить "Раз у Вас нет - то и у других не должно быть?"
15 сен 17, 13:40    [20798726]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
hVostt
Кот Матроскин
для случая "корзина в отдельной таблице", вся разница - в том что у Вас будет CustomerID, а не OrderID.


OrderID в корзине вообще не нужен. На одну корзину может быть создано несколько заказов, а CustomerId нужен всегда.

Нет, в случае наличия OrderID customerID в корзине не нужен. Тут даже на 2 шага вперед думать необязательно - это прямо на нулевом шаге видно :)
15 сен 17, 13:42    [20798737]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
tip78
Member

Откуда: Москва
Сообщений: 442
hVostt
tip78
hVostt
пропущено...


Дело даже не в этом. Само наличие заказа подразумевает начало некоего workflow, появление нового заказа в системе это событие. А работа с корзиной это совершенно отдельная история. С корзиной могут быть связаны совершенно другие процессы.

какие?


Что какие? Заказ сам себя сформирует, проведёт и проверит оплату, укомплектуется, и сам себя передаст в службу доставки? Где сам себя доставит и проконтролирует?

это процессы не с корзиной, а с заказом (у меня это одна сущность, у вас - 2). Я спрашивал - какие "совершенно другие процессы" вы делаете с корзиной, что её непременно надо отделять от заказа? Если хотите хранить все клиентские "добавить/удалить" (кому они нужны?), то сделайте таблицу истории.

hVostt
tip78
для этого статусы есть, как тут 20796966
и вообще "история заказа" это другая сущность (если она вам действительно нужна подробная), а не корзина + заказ


Корзина не является заказом. Это не статус заказа. Не согласны?

вы всё пытаетесь привязать к корзине какие-то события, которые непременно надо обрабатывать отдельно от заказа,
но их НЕТ. И это ключевой момент.
всё что юзер собрал в заказ просто едет дальше, а история наполнения/редактирования - ну ведите, если надо, в отдельной таблице, только это просто статусы, они не разбивают заказ на ДО = корзина и ПОСЛЕ = заказ.
15 сен 17, 13:51    [20798783]     Ответить | Цитировать Сообщить модератору
 Re: Реляционка тут бессильна?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 2843
Кот Матроскин
Ennor Tiegael
пропущено...
В большинстве магазинов аноним может зайти и начать собирать корзину до авторизации. Будете в БД анонимный заказ сохранять? И отличаете их потом, наверное, как-то друг от друга?

Конечно - анонимного пользователя с идентификацией по кукам и для него обычную корзину.
Я еще раз повторяю - точно так же Вам придется сохранить анонимного пользователя
для случая "корзина в отдельной таблице", вся разница - в том что у Вас будет CustomerID, а не OrderID.
Анонимный пользователь будет хранить свою корзину в локальной куке и нигде более. Полагаю, что спецслужбы знают способ, как сопоставить 2 анонимные сессии с разных айпишников, но мне он неизвестен.

Ключевое же отличие в том, что клиент, действительно, есть всегда, а вот заказ появляется только после того, как пользователь:
  • Авторизовался;
  • Нажал submit.

    А там, где нет заказа, нет и OrderId. Чел может днями играться со своей корзиной, а потом все нафиг стереть и ничего не взять - понятно, что для какого-нибудь поведенческого дата майнинга вся эта история действий может быть полезной, не это все-таки совсем притягивание за уши.
  • 15 сен 17, 13:53    [20798793]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    hVostt
    Member

    Откуда:
    Сообщений: 11352
    Кот Матроскин
    Нет, в случае наличия OrderID customerID в корзине не нужен. Тут даже на 2 шага вперед думать необязательно - это прямо на нулевом шаге видно :)


    Т.е. не получится сделать 2 разных заказа на 1 корзину? Ясненько.
    15 сен 17, 13:55    [20798802]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    hVostt
    Member

    Откуда:
    Сообщений: 11352
    tip78
    это процессы не с корзиной, а с заказом (у меня это одна сущность, у вас - 2). Я спрашивал - какие "совершенно другие процессы" вы делаете с корзиной, что её непременно надо отделять от заказа? Если хотите хранить все клиентские "добавить/удалить" (кому они нужны?), то сделайте таблицу истории.


    Историчность -- отдельная песня. Зачем я буду логику класть на историчность?


    tip78
    вы всё пытаетесь привязать к корзине какие-то события, которые непременно надо обрабатывать отдельно от заказа,
    но их НЕТ. И это ключевой момент.


    Как это нет? А уведомление: вы положили в корзину товары, но не оформили заказ? А уведомление, товар, который вы добавили в корзину появился в наличии? Вы в каком мире живёте, в вымышленном, если у вас таких событий нет?


    tip78
    всё что юзер собрал в заказ просто едет дальше, а история наполнения/редактирования - ну ведите, если надо, в отдельной таблице, только это просто статусы, они не разбивают заказ на ДО = корзина и ПОСЛЕ = заказ.


    Дальше едет заказ. Вы в жизни посмотрите как это делается. Придите в магазин. Что видите? Корзину. Или вы сразу сразу оформляете чек?
    15 сен 17, 13:58    [20798814]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    Кот Матроскин
    Member

    Откуда: Москва
    Сообщений: 7569
    Ennor Tiegael
    Кот Матроскин
    пропущено...

    Конечно - анонимного пользователя с идентификацией по кукам и для него обычную корзину.
    Я еще раз повторяю - точно так же Вам придется сохранить анонимного пользователя
    для случая "корзина в отдельной таблице", вся разница - в том что у Вас будет CustomerID, а не OrderID.
    Анонимный пользователь будет хранить свою корзину в локальной куке и нигде более.

    "Если у Вас так, то и у других должно быть так? Понятненько" (с)
    У меня хранятся в базе корзины анонимных пользователей. И да, статистические отчеты по этим корзинам для отдела продаж есть.
    15 сен 17, 13:59    [20798822]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    tip78
    Member

    Откуда: Москва
    Сообщений: 442
    Ennor Tiegael
    tip78
    пропущено...

    чтобы товар попадал в его корзину, а не в чужую
    а ещё когда UID нет (авторизации не было), тоже надо как-то товар ловить...
    В большинстве магазинов аноним может зайти и начать собирать корзину до авторизации. Будете в БД анонимный заказ сохранять? И отличаете их потом, наверное, как-то друг от друга?

    не "буду", а сохраняю )
    во1, это статистика, её можно поанализировать
    во2, опять же всё в одном месте (где ещё их хранить и зачем?)
    в3, клиенту напоминалка придёт про его незаконченную корзину
    в4, через какое-то время незаконченные удаляются
    15 сен 17, 14:02    [20798838]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    Кот Матроскин
    Member

    Откуда: Москва
    Сообщений: 7569
    hVostt
    Кот Матроскин
    Нет, в случае наличия OrderID customerID в корзине не нужен. Тут даже на 2 шага вперед думать необязательно - это прямо на нулевом шаге видно :)


    Т.е. не получится сделать 2 разных заказа на 1 корзину? Ясненько.

    Глупости :)
    Вам надо как-то переформатировать свои сообщения - писать "Дяденька, а как сделать 2 разных заказа на одну корзину в случае хранения в одной таблице? Я не умею :(" - не исключено что так Вы скорее научитесь :)
    15 сен 17, 14:02    [20798840]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    tip78
    Member

    Откуда: Москва
    Сообщений: 442
    тьфу, напоминалка не в этом случае ))
    15 сен 17, 14:03    [20798846]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    Ennor Tiegael
    Member

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

    Что вы действительно упускаете, так это лес за деревьями. Данные в корзине по природе своей временные. Лично мне в базе они вообще не нужны - строго говоря, для них даже РСУБД не нужна, достаточно простейшего blob list. Поэтому я выношу таблицу корзины в отдельную БД, ставлю ей simple recovery и экономлю на бэкапах лога (в оракле, вроде бы, можно на уровне таблиц логирование отключать). Если что-то гавкнется, то потери будут минимальны и не критичны.
    15 сен 17, 14:16    [20798896]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    Ennor Tiegael
    Member

    Откуда:
    Сообщений: 2843
    hVostt
    А уведомление: вы положили в корзину товары, но не оформили заказ? А уведомление, товар, который вы добавили в корзину появился в наличии?
    Кстати, да, совершенно забыл. Окей, согласен, корзину надо хранить в БД - но никто не требует, что это должна быть та же БД.
    15 сен 17, 14:25    [20798927]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    Кот Матроскин
    Member

    Откуда: Москва
    Сообщений: 7569
    Ennor Tiegael
    Наоборот - это у заказа есть действия, которые отсутствуют у корзины.

    У заказа в комплектации есть действия, которые отсутствуют у отправленного заказа, у отправленного - те которые отсутствуют у выполненного, etc. Тоже будем бить их на разные классы/таблицы? :)
    15 сен 17, 14:31    [20798942]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    Ennor Tiegael
    Member

    Откуда:
    Сообщений: 2843
    tip78
    в3, клиенту напоминалка придёт про его незаконченную корзину
    Ммм? Анониму?
    tip78
    в4, через какое-то время незаконченные удаляются
    Если каждый заказ - это событие, то возможно. Когда их сотни тысяч в день, удаление из такой таблицы будет вести к фрагментации, а ребилдить индексы в 24*7 системе обычно непросто. Мне здравый смысл подсказывает, что можно сэкономить на дефрагментации, не записывая туда данные, которые могут быть впоследствии удалены.
    15 сен 17, 14:37    [20798962]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    Ennor Tiegael
    Member

    Откуда:
    Сообщений: 2843
    Кот Матроскин
    Ennor Tiegael
    Наоборот - это у заказа есть действия, которые отсутствуют у корзины.

    У заказа в комплектации есть действия, которые отсутствуют у отправленного заказа, у отправленного - те которые отсутствуют у выполненного, etc. Тоже будем бить их на разные классы/таблицы? :)
    Где вас учили так перегибать палку с использованием reductio ad absurdum? Толсто же.

    Кстати говоря - да, их действительно имеет смысл разносить по разным таблицам. Точнее, на разных этапах воркфлоу заказ обрастает дополнительными данными, которые отсутствовали на предыдущих стадиях. Разбивка по складам, в общем случае, может быть неизвестна в самом начале, и заполняться позже. Трекинг(и) доставки появляются только после отправки. Оплата - я говорю о цивилизованных странах, где cash on delivery большая редкость - вообще целая отдельная вселенная. Я надеюсь, вы понимаете, что все это, и многое другое, хранится в своих собственных таблицах, а не в позициях заказа.

    С моей т.з. главное тут, что оформленные заказы во всех последующих стадиях одинаково персистентны. Корзина же временная по своей природе, и схема данных у нее совсем другая.
    15 сен 17, 14:52    [20799033]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    MasterZiv
    Member

    Откуда: Питер
    Сообщений: 33420
    registerers
    Суть проблемы можно пояснить на примере того же банального интернет-магазина. Есть множество таблиц разных товаров, потому что набор свойств (атрибутов) у них разный. Например, булка хлеба и како-нибудь девайс. Вопрос - как положить в корзину и то, и другое, и пятое-десятое?


    Ответ на твой "супер-сложный" вопрос так же суперпрост:
    надо использовать наследование, оно же отношение подкатегории (между сущностями).
    Вжух -- и нет проблем!
    15 сен 17, 16:30    [20799445]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    registerers
    Member

    Откуда:
    Сообщений: 47
    MasterZiv
    Ответ на твой "супер-сложный" вопрос так же суперпрост:
    надо использовать наследование, оно же отношение подкатегории (между сущностями).
    Вжух -- и нет проблем!

    Тут тема не про объектно-ориентированные, а про реляционные БД. Какое наследование?
    15 сен 17, 17:27    [20799639]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    skyANA
    Member

    Откуда: Зеленоград
    Сообщений: 22601
    registerers
    MasterZiv
    Ответ на твой "супер-сложный" вопрос так же суперпрост:
    надо использовать наследование, оно же отношение подкатегории (между сущностями).
    Вжух -- и нет проблем!

    Тут тема не про объектно-ориентированные, а про реляционные БД. Какое наследование?

    Вы разве не знаете, что наследование реализуется в виде связи 1-к-1 между 2-мя таблицами?
    15 сен 17, 17:28    [20799644]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    skyANA
    Member

    Откуда: Зеленоград
    Сообщений: 22601
    На примере MS SQL.

    CREATE TABLE fin.Document (
        Id INT IDENTITY(1,1) NOT NULL,
        CONSTRAINT PK_Document PRIMARY KEY CLUSTERED (Id)
    )
    GO
    


    CREATE TABLE fin.Invoice (
        Id INT NOT NULL,
        CONSTRAINT PK_Invoice PRIMARY KEY CLUSTERED (Id)
    )
    GO
    
    ALTER TABLE fin.Invoice ADD CONSTRAINT FK_Invoice_Document FOREIGN KEY(Id) REFERENCES fin.Document (Id)
    GO
    
    ALTER TABLE fin.Invoice CHECK CONSTRAINT FK_Invoice_Document
    GO
    
    15 сен 17, 17:39    [20799664]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    MasterZiv
    Member

    Откуда: Питер
    Сообщений: 33420
    skyANA
    registerers
    пропущено...

    Тут тема не про объектно-ориентированные, а про реляционные БД. Какое наследование?

    Вы разве не знаете, что наследование реализуется в виде связи 1-к-1 между 2-мя таблицами?


    в виде связи 1-к-0..1 между 2-мя таблицами
    15 сен 17, 17:42    [20799672]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    MasterZiv
    Member

    Откуда: Питер
    Сообщений: 33420
    registerers
    MasterZiv
    Ответ на твой "супер-сложный" вопрос так же суперпрост:
    надо использовать наследование, оно же отношение подкатегории (между сущностями).
    Вжух -- и нет проблем!

    Тут тема не про объектно-ориентированные, а про реляционные БД. Какое наследование?


    Ты спрашивал -- я тебе ответил. Кстати, то же ответили тебе прямо или косвенно намекали на это некоторые другие
    отвечающие.

    Вопрос исчерпан, тему можно закрывать.
    Есть другие вопросы -- задавай отдельно.
    15 сен 17, 17:44    [20799679]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    zeon11
    Member

    Откуда: Сибирь, Кемерово
    Сообщений: 1042
    Ennor Tiegael
    tip78
    в3, клиенту напоминалка придёт про его незаконченную корзину
    Ммм? Анониму?
    tip78
    в4, через какое-то время незаконченные удаляются
    Если каждый заказ - это событие, то возможно. Когда их сотни тысяч в день, удаление из такой таблицы будет вести к фрагментации, а ребилдить индексы в 24*7 системе обычно непросто. Мне здравый смысл подсказывает, что можно сэкономить на дефрагментации, не записывая туда данные, которые могут быть впоследствии удалены.


    Вот что-бы отсутствовала фрагментация и не стоит данные удалять, поскольку не оформленный заказ, т.е. пустая корзина имеет определённую ценность. Банальная уже фраза "отрицательный результат - то-же результат" - работает. Думаю, что хороший проектировщик оставит пустые корзины в БД, поскольку АНОНИМ в наше время совсем и не аноним, есть время входа на сайт, есть попытки наполнить корзину товарами, есть интервалы между закидками товара в корзину, есть корреляции между товарами, брендами, да и много чего полезного можно нарыть. Не обязательно сразу "вываливать" весь потенциал в продакшн, но когда клиент созреет до развернутой аналитики, у вас для реализации его хотелок уже всё будет готово.
    15 сен 17, 17:45    [20799680]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    hVostt
    Member

    Откуда:
    Сообщений: 11352
    Кот Матроскин
    Глупости :)
    Вам надо как-то переформатировать свои сообщения - писать "Дяденька, а как сделать 2 разных заказа на одну корзину в случае хранения в одной таблице? Я не умею :(" - не исключено что так Вы скорее научитесь :)


    Какой-то детсадовский способ на понт брать. Если вы головой лупашите в стену, это не значит что я буду доказывать вам, что я тоже так могу.
    15 сен 17, 18:42    [20799775]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    hVostt
    Member

    Откуда:
    Сообщений: 11352
    Ennor Tiegael
    hVostt
    А уведомление: вы положили в корзину товары, но не оформили заказ? А уведомление, товар, который вы добавили в корзину появился в наличии?
    Кстати, да, совершенно забыл. Окей, согласен, корзину надо хранить в БД - но никто не требует, что это должна быть та же БД.


    Именно.
    15 сен 17, 18:43    [20799776]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    registerers
    Member

    Откуда:
    Сообщений: 47
    MasterZiv
    registerers
    пропущено...

    Тут тема не про объектно-ориентированные, а про реляционные БД. Какое наследование?


    Ты спрашивал -- я тебе ответил. Кстати, то же ответили тебе прямо или косвенно намекали на это некоторые другие
    отвечающие.

    Вопрос исчерпан, тему можно закрывать.
    Есть другие вопросы -- задавай отдельно.

    Тогда надо определиться в терминологии, что называть наследованием в данном случае. К тому же, как быть в ситуации, когда одинаково названы поля в родительской и дочерней таблицах?

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

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

    З.Ы. А по логике корзины - целесообразно создать отдельный топик, тема довольно интересная, но здесь это оффтоп.
    15 сен 17, 19:50    [20799872]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    hVostt
    Member

    Откуда:
    Сообщений: 11352
    registerers
    Введение дискриминатора в состав ключа, как предлагал известный персонаж из Простоквашино в посте 20787976 ещё более костыльное решение, нигде такого не встречал...


    Он из параллельной вселенной :)


    registerers
    В общем, подытожим. Вывод такой, что нельзя однозначно ответить на вопрос топика - "да" или "нет". Реляционка позволяет реализовать отношения вида тип-подтип, но контроль за ограничениями, о которых говорилось выше, ложится на приложение.


    А где это не так вообще?
    Кто вообще закладывает какие-нибудь бизнес ограничения на реляционку?
    15 сен 17, 20:04    [20799895]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    registerers
    Member

    Откуда:
    Сообщений: 47
    [quot hVostt]
    registerers
    Кто вообще закладывает какие-нибудь бизнес ограничения на реляционку?

    Это не бизнес-ограничения, а обеспечение целостности и непротиворечивости данных
    15 сен 17, 21:00    [20799970]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    skyANA
    Member

    Откуда: Зеленоград
    Сообщений: 22601
    MasterZiv
    skyANA
    пропущено...

    Вы разве не знаете, что наследование реализуется в виде связи 1-к-1 между 2-мя таблицами?


    в виде связи 1-к-0..1 между 2-мя таблицами

    И так и эдак бывает. В примере выше у меня Документ - это абстрактная сущность.
    15 сен 17, 21:30    [20800009]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    hVostt
    Member

    Откуда:
    Сообщений: 11352
    registerers
    registerers
    Кто вообще закладывает какие-нибудь бизнес ограничения на реляционку?

    Это не бизнес-ограничения, а обеспечение целостности и непротиворечивости данных


    Ну я и спросил, где это не так в случае с наследованием? И какие трудности в терминологии?
    15 сен 17, 21:31    [20800012]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    skyANA
    Member

    Откуда: Зеленоград
    Сообщений: 22601
    registerers
    Тогда надо определиться в терминологии, что называть наследованием в данном случае.

    Наследованием в базе данных называют, внезапно, отношения наследования :)
    15 сен 17, 21:33    [20800015]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    registerers
    Member

    Откуда:
    Сообщений: 47
    Ой всё...
    15 сен 17, 21:41    [20800032]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    tip78
    Member

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

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


    Ennor Tiegael
    tip78
    в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):

    Ссылка на позицию в клипе: http://youtu.be/P__hN6u9yCw?t=11m20s

    НО при этом почему-то он ничего не сказал про альтернативы, какие-то свои наработки и вообще ЧТО делать.
    Ок, попробую я. В Интернете (хабр/тостер/ЛОР/stackexchange) полно статей недовольных EAV, но при этом авторы сами не умеют ни правильно оптимизировать БД (не запросы), ни полностью использовать её инструменты, ни совмещать РБД с носкл на уровне приложения (самый важный момент).

    Чтобы нормально решать подобные задачи, достаточно просто быть хорошим RDBA + программистом.
    А вот чтобы решать их супер-эффективно нужно быть на пару ступенек выше простого RDBA.
    Вам ещё предстоит выяснить, что от свойств меняется цена (дубовый пол дороже букового. Меняется в обе стороны причём (скидки)), что бывают акции (купи две, третья бесплатно), что в одном магазине может быть дороже другого (магазин на рублёвке).
    И эффективное решение всех этих технических моментов делает один магазин лучше другого, что называется "конкуренцией" ;)

    Конкретно ваш вопрос:
    автор
    Например, булка хлеба и какой-нибудь девайс. Вопрос - как положить в корзину и то, и другое, и пятое-десятое?

    решается таблицами: заказы, товары в заказе (НФ), выбранные свойства в товаре в заказе, статусы заказа
    и парой функций.
    где именно ставится цена, зависит от того, как вы победили свойства.
    16 сен 17, 18:02    [20800860]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    stenford
    Member

    Откуда: урал
    Сообщений: 2176
    registerers
    В общем, подытожим. Вывод такой, что нельзя однозначно ответить на вопрос топика - "да" или "нет". Реляционка позволяет реализовать отношения вида тип-подтип, но контроль за ограничениями, о которых говорилось выше, ложится на приложение.

    есть-же обьектно-ориентированные базы данных, используй их, там тебе будут и типы, и наследование и никаких проблем с маппингом на классы не будет и вообще с идеологией все прекрасно, прямо как в коммунизме. Но нет, почему-то в теории все хорошо, а на практике берут и используют реляционку
    Почему? А потому, что на практике таких проблем нет. Когда тебе надо получить определенный подтип, то он тебе уже известен и известна таблица с которой нужен джойн. Да, в случае использования одиночного int'ого ключа база не будет гарантировать, что в таблица ссылается на правильный тип, это не является практической проблемой т.к. в случае джойна с такой записью резалтсет будет просто пустой. Как и в случае если запись реально отсутствует в таблице подтипа, и реляционка тут опять "бессильна", ну не может она гарантировать что ты добавил эту запись в нужную таблицу. Не может завод Мерседес гарантировать, что на его машине ты не поедешь пахать поля с картошкой. Это не от завода зависит, и не от модели, а от водителя
    17 сен 17, 01:52    [20801100]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    skyANA
    Member

    Откуда: Зеленоград
    Сообщений: 22601
    stenford
    есть-же обьектно-ориентированные базы данных, используй их, там тебе будут и типы, и наследование и никаких проблем с маппингом на классы не будет и вообще с идеологией все прекрасно, прямо как в коммунизме. Но нет, почему-то в теории все хорошо, а на практике берут и используют реляционку

    Странное утверждение, на практике кто-то использует реляционку, а кто-то и MongoDB: Top 3 Node JS eCommerce platforms.
    17 сен 17, 09:53    [20801185]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    skyANA
    Member

    Откуда: Зеленоград
    Сообщений: 22601
    Да и тема использования не первый год обсуждается.
    Вот к примеру статья 10-го года: http://web.archive.org/web/20110713174947/http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/
    17 сен 17, 10:01    [20801191]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    stenford
    Member

    Откуда: урал
    Сообщений: 2176
    skyANA
    Странное утверждение, на практике кто-то использует реляционку, а кто-то и MongoDB: Top 3 Node JS eCommerce platforms.

    MongoDB НЕ является обьектно-ориентированной БД
    17 сен 17, 13:02    [20801374]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    skyANA
    Member

    Откуда: Зеленоград
    Сообщений: 22601
    stenford
    skyANA
    Странное утверждение, на практике кто-то использует реляционку, а кто-то и MongoDB: Top 3 Node JS eCommerce platforms.

    MongoDB НЕ является обьектно-ориентированной БД

    Да не является. Я просто подумал, что Вы немного о другом.

    Изначальный-то вопрос звучит так: "Есть множество разных товаров... набор свойств (атрибутов) у них разный... как положить в корзину и то, и другое, и пятое-десятое?".

    C MongoDB это не проблема. Да и вообще для объектно-ориентированных данных документо-ориентированная БД в определённых смыслах больше подходит.
    17 сен 17, 13:17    [20801383]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    Bsplesk
    Member

    Откуда:
    Сообщений: 30
    Так, так, как уже выше заметили, куда там magento соскочило c EAV? :).
    Смотрим таблицы начинающиеся с "bingo" c EAV(eav_entity/eav_attribyte/eav_entity_type-->eav_entity_decimal) и их кол-во.
    ER schema magento 2.1.3 Community Edition

    "Космодемьянский ругал EAV тут (11:20)" - все ругают бедный EAV, тем более EAV/CR, заодно и ORM, но вот предложений, как выполнять требования бизнеса которые позволяет решать EAV/ORM (он часто и генерирует эти "жуткие" запросы), из разряда "How-to" ... молчок и обычно следует ... приходите к нам и за $$$ мы Вас научим :), что Вам не нужны такие задачи, и Вы вообще живёте неправильно, и всякие bitrix/1c/SAP/....прочие ERP, аналогично и.т.д.

    автор
    Не согласен - критикуй, критикуешь - предлагай, предлагаешь - делай, делаешь - отвечай!


    И да, как там поживает суррогатный ключ в теории :) ?
    Всё-таки надо побороть жадность, сгонять на pgConf, вживую его послушать, позадавать вопросы ... особенно про EAV и как быстро подстраиваться под изменчивый бизнес.

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

    EAV старый, медленный, и гибкий "антипаттерн" с которым все умеют работать и работают.

    И не у всех "BigData", "HighLoad++", "Машин лёрнинг"
    автор
    Вот где карту открывали, туда и идите"/TOP1 с BigData.
    17 сен 17, 18:02    [20801689]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    tip78
    Member

    Откуда: Москва
    Сообщений: 442
    Bsplesk
    Может просветит неразумного, а то мы все jsonb мучаем, и уже до jquery добрались, и огребаем по полной в надежде на развитие PG.

    полагаю вы про Jsquery
    18 сен 17, 10:32    [20802683]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    Кот Матроскин
    Member

    Откуда: Москва
    Сообщений: 7569
    Bsplesk
    и Вы вообще живёте неправильно, и всякие bitrix/1c/SAP/....прочие ERP, аналогично и.т.д.

    bitrix/1C/SAP - как раз не аналогично.
    Для тиражной системы, перед которой стоит задача "чтобы тысячи мартышек на местах могли нас допиливать, но не могли сломать" - да, EAV вполне неплохое и рабочее решение для этой задачи.
    18 сен 17, 10:56    [20802748]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    АнатоЛой
    Member

    Откуда: Киев, Украина
    Сообщений: 2896
    Блог
    registerers

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

    Что именно хотите видеть в результатах? И допишите реальные реквизиты у таблиц...
    18 сен 17, 22:48    [20804756]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    registerers
    Member

    Откуда:
    Сообщений: 47
    АнатоЛой
    registerers
    Кстати, если это не костыль, то напишите JOIN-запрос для такого кейса)))

    Что именно хотите видеть в результатах? И допишите реальные реквизиты у таблиц...


    Дано: таблица супер-типа и множество таблиц под-типов (например, видов товаров)
    Требуется: вывести все записи из таблицы супер-типа с заджоиненным произвольным полем (например, именем) из каждой таблицы под-типа

    Я понимаю, что запрос должен быть чем то вроде этого:
    SELECT sub1.field FROM supertable AS super JOIN subtable1 AS sub1 ON sub1.id = super.id WHERE super.type = 'sub1'
    UNION
    SELECT sub2.field FROM supertable AS super JOIN subtable2 AS sub1 ON sub2.id = super.id WHERE super.type = 'sub2'
    UNION
    SELECT sub3.field FROM supertable AS super JOIN subtable3 AS sub1 ON sub3.id = super.id WHERE super.type = 'sub3'
    

    Но ведь вопрос в том, что нужно заранее знать, какие типы под-типы существуют, а реляционная теория не позволяет абстрагировать эту задачу на произвольные наборы под-типов. Вот если бы существовал условный механизм объединения подобный таковому в случае слияния, что-то вроде "UNION ON" тогда другой вопрос. А так, выглядит, что реляционная теория неполна.

    P.S. Надеюсь на конструктивный диалог, в отличие от некоторых товарищей, комментировавших выше.
    22 сен 17, 01:34    [20814236]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    MasterZiv
    Member

    Откуда: Питер
    Сообщений: 33420
    registerers
    MasterZiv
    пропущено...


    Ты спрашивал -- я тебе ответил. Кстати, то же ответили тебе прямо или косвенно намекали на это некоторые другие
    отвечающие.

    Вопрос исчерпан, тему можно закрывать.
    Есть другие вопросы -- задавай отдельно.

    Тогда надо определиться в терминологии, что называть наследованием в данном случае. К тому же, как быть в ситуации, когда одинаково названы поля в родительской и дочерней таблицах?

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

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

    З.Ы. А по логике корзины - целесообразно создать отдельный топик, тема довольно интересная, но здесь это оффтоп.



    ты фантазёр, однако...
    22 сен 17, 06:10    [20814278]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    MasterZiv
    Member

    Откуда: Питер
    Сообщений: 33420
    skyANA
    MasterZiv
    пропущено...


    в виде связи 1-к-0..1 между 2-мя таблицами

    И так и эдак бывает. В примере выше у меня Документ - это абстрактная сущность.



    родитель один у , скажем двух классов.
    его связь с каждой из дочерних таблиц один к ноль или один, потому что записей в обоих дочерних классах может не быть , т.е. в каждом наследнике запись либо она, либо её нет вообше.
    поэтому и 1:0..1 , а не "бывает так и эдак" .
    22 сен 17, 06:17    [20814279]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    MasterZiv
    Member

    Откуда: Питер
    Сообщений: 33420
    registerers
    АнатоЛой
    пропущено...

    Что именно хотите видеть в результатах? И допишите реальные реквизиты у таблиц...


    Дано: таблица супер-типа и множество таблиц под-типов (например, видов товаров)
    Требуется: вывести все записи из таблицы супер-типа с заджоиненным произвольным полем (например, именем) из каждой таблицы под-типа

    Я понимаю, что запрос должен быть чем то вроде этого:
    SELECT sub1.field FROM supertable AS super JOIN subtable1 AS sub1 ON sub1.id = super.id WHERE super.type = 'sub1'
    UNION
    SELECT sub2.field FROM supertable AS super JOIN subtable2 AS sub1 ON sub2.id = super.id WHERE super.type = 'sub2'
    UNION
    SELECT sub3.field FROM supertable AS super JOIN subtable3 AS sub1 ON sub3.id = super.id WHERE super.type = 'sub3'
    

    Но ведь вопрос в том, что нужно заранее знать, какие типы под-типы существуют, а реляционная теория не позволяет абстрагировать эту задачу на произвольные наборы под-типов. Вот если бы существовал условный механизм объединения подобный таковому в случае слияния, что-то вроде "UNION ON" тогда другой вопрос. А так, выглядит, что реляционная теория неполна.

    P.S. Надеюсь на конструктивный диалог, в отличие от некоторых товарищей, комментировавших выше.


    Чё там не скачаешь ты фишку нигде ниразу...

    дело в том, что тебе не нужно знать все подтипы, а поле это общее должно быть в базовом классе.
    да и запрос у тебя неправильный.

    мне кажется уже в психологии у тебя проблемым ты просто не хочешь понимать то, что видимо понять способен. и этот ментальный барьер только тебе и мешает.
    22 сен 17, 06:30    [20814281]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    MasterZiv
    Member

    Откуда: Питер
    Сообщений: 33420
    MasterZiv,
    скачаешь/сечёшь
    22 сен 17, 06:31    [20814283]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    skyANA
    Member

    Откуда: Зеленоград
    Сообщений: 22601
    MasterZiv
    skyANA
    пропущено...

    И так и эдак бывает. В примере выше у меня Документ - это абстрактная сущность.



    родитель один у , скажем двух классов.
    его связь с каждой из дочерних таблиц один к ноль или один, потому что записей в обоих дочерних классах может не быть , т.е. в каждом наследнике запись либо она, либо её нет вообше.
    поэтому и 1:0..1 , а не "бывает так и эдак" .

    В примере выше не бывает записи только в таблице fin.Document, то есть не бывает ситуации "либо её нет вообше". Понимаете?

    Назовём это "наследование от абстрактного класса" :)
    22 сен 17, 07:15    [20814300]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    tip78
    Member

    Откуда: Москва
    Сообщений: 442
    я вообще уже запутался, что за "супер-типы" начались? кто это?

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

    у "банального интернет-магазина" нет проблем. "Банально" там достаточно знать все ID, которые встречаются, выполнить 1 IN-query и вытащить карту соответствий, которой потом и пользоваться при выводе.
    22 сен 17, 12:35    [20815412]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    tip78
    Member

    Откуда: Москва
    Сообщений: 442
    забыл добавить, что у вас он НЕ банальный, отсюда и все беды
    22 сен 17, 12:49    [20815490]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    skyANA
    Member

    Откуда: Зеленоград
    Сообщений: 22601
    tip78
    забыл добавить, что у вас он НЕ банальный, отсюда и все беды

    Ну он же чёрным по белому написал в первом посте: "Вот есть такой теоретический вопрос о реляционных связях между гетерогенными структурами данных" :)
    22 сен 17, 13:13    [20815614]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    registerers
    Member

    Откуда:
    Сообщений: 47
    Да уж, я смотрю, тут собрались почти одни снобы и тролли, которым нечего сказать по сути кроме демагогии и переходов на личность собеседника. Надеюсь, что найдётся хоть один адекватный спец в реляционке, который понимает суть проблемы...
    22 сен 17, 15:26    [20816394]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    ViPRos
    Member

    Откуда:
    Сообщений: 7917
    registerers,

    да суть то простая
    нельзя указать форинкей к вью
    потому приходится делать промежуточную таблицу (Union всех ID всех таблиц)
    22 сен 17, 15:52    [20816584]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    registerers
    Member

    Откуда:
    Сообщений: 47
    ViPRos
    registerers,

    да суть то простая
    нельзя указать форинкей к вью
    потому приходится делать промежуточную таблицу (Union всех ID всех таблиц)


    та не, вьюхи тут не при чём
    это скорее вопрос о монопольном владении внешним ключом
    (похоже на рэпчину))
    22 сен 17, 16:02    [20816639]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    tip78
    Member

    Откуда: Москва
    Сообщений: 442
    skyANA
    tip78
    забыл добавить, что у вас он НЕ банальный, отсюда и все беды

    Ну он же чёрным по белому написал в первом посте: "Вот есть такой теоретический вопрос о реляционных связях между гетерогенными структурами данных" :)

    какой же он теоретический? "наполнить корзину", это самый обязательный вопрос в любом магазине.
    не надо было под каждый вид товара создавать отдельную таблицу с его свойствами. Тысячи их.
    jsonb добавьте в order_products и зафиксируйте все выбранные свойства. Нельзя там IDы свойств держать, свойства ведь могут и исчезнуть через X лет.
    22 сен 17, 16:17    [20816718]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    skyANA
    Member

    Откуда: Зеленоград
    Сообщений: 22601
    tip78
    skyANA
    пропущено...

    Ну он же чёрным по белому написал в первом посте: "Вот есть такой теоретический вопрос о реляционных связях между гетерогенными структурами данных" :)

    какой же он теоретический? "наполнить корзину", это самый обязательный вопрос в любом магазине.
    не надо было под каждый вид товара создавать отдельную таблицу с его свойствами. Тысячи их.
    jsonb добавьте в order_products и зафиксируйте все выбранные свойства. Нельзя там IDы свойств держать, свойства ведь могут и исчезнуть через X лет.

    Магазины появились ещё до jsonb и проблем с добавлением товара в корзину у них нет. Автор таки теоритизирует :)
    22 сен 17, 17:15    [20816967]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    registerers
    Member

    Откуда:
    Сообщений: 47
    skyANA
    tip78
    пропущено...

    какой же он теоретический? "наполнить корзину", это самый обязательный вопрос в любом магазине.
    не надо было под каждый вид товара создавать отдельную таблицу с его свойствами. Тысячи их.
    jsonb добавьте в order_products и зафиксируйте все выбранные свойства. Нельзя там IDы свойств держать, свойства ведь могут и исчезнуть через X лет.

    Магазины появились ещё до jsonb и проблем с добавлением товара в корзину у них нет. Автор таки теоритизирует :)

    Конечно, теоретизирую, я с самого начала говорил, что меня интересует исключительно теория. Я в своей практике рефакторил достаточно разных систем и насмотрелся разного. Проблем с добавлением в корзину нет, но решаются они костыльным способом. Об этом идёт речь. Только введение ограничения монопольного владения внешним ключом могло бы решить проблему. Но, наверное, это будет не в этой Вселенной... Хотя, написать чувакам из рабочей группы ISO/IEC, наверное стоит)) Возможно там будет дискуссия более продуктивная, чем здесь)))
    22 сен 17, 21:52    [20817393]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    Бредятина
    Member

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

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

    Картинка с другого сайта.

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

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

    Сначала, все-таки, нужно ответить себе на вопрос: а почему не все товары в одной таблице?:) Что в этом плохого, конкретно?
    23 сен 17, 21:11    [20818338]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    Бредятина
    Member

    Откуда: Москва
    Сообщений: 1654
    ViPRos
    registerers,

    да суть то простая
    нельзя указать форинкей к вью
    потому приходится делать промежуточную таблицу (Union всех ID всех таблиц)

    )))
    Во-первых, Вы находитесь в разделе "Проектирование баз данных", а не "Проектирование реляционных баз данных".
    Во-вторых, для РМД еще не удалось найти ни одной практической задачи, то есть, ее практическая ценность равна нулю.
    23 сен 17, 21:21    [20818354]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    zeon11
    Member

    Откуда: Сибирь, Кемерово
    Сообщений: 1042
    Бредятина,

    Это-же Ваш человек!
    Вы - отрицаете реляционные БД, ТС - сомневается в них. Ему ещё один шаг, и вас тут на форуме будет двое.
    24 сен 17, 18:15    [20819072]     Ответить | Цитировать Сообщить модератору
     Re: Реляционка тут бессильна?  [new]
    Бредятина
    Member

    Откуда: Москва
    Сообщений: 1654
    zeon11
    Бредятина,

    Это-же Ваш человек!
    Вы - отрицаете реляционные БД, ТС - сомневается в них. Ему ещё один шаг, и вас тут на форуме будет двое.

    Я ничего не отрицаю, всегда сомневаюсь, и никогда свое мнение не высказываю:) Мнение может обидеть какого-нибудь (совсем не знакомого) человека:) Факты, конечно, тоже могут обидеть, но это уже проблема обиженного. Как правило:)
    25 сен 17, 14:36    [20820879]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: 1 2 3 4 5 6 7      [все]
    Все форумы / Проектирование БД Ответить