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

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

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

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

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

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

Откуда: Зеленоград
Сообщений: 22641
На примере 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

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

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

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


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

Откуда: Питер
Сообщений: 33434
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

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


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

Откуда:
Сообщений: 11397
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

Откуда:
Сообщений: 11397
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

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

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


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

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

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

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


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

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

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

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

Откуда: Москва
Сообщений: 444
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

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

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

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

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

Откуда: Зеленоград
Сообщений: 22641
Да и тема использования не первый год обсуждается.
Вот к примеру статья 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

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

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

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

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

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

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

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

Откуда:
Сообщений: 31
Так, так, как уже выше заметили, куда там 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

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

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

Откуда: Москва
Сообщений: 7579
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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7   вперед  Ctrl      все
Все форумы / Проектирование БД Ответить