zelenin писал(а): ↑2018.03.17, 02:20
это бизнес-знание - тип лежащей в заказе сущности. Указывает оно на местоположение данных или на специфический обсчет элемента заказа - собственно решать приложению.
А с точки зрения проектирования схем реляционных баз - недостаток.
zelenin писал(а): ↑2018.03.17, 02:20
плюсы и минусы известны. вынося защиту целостности в приложение, более компактная схема предпочтительнее, чем дублирование таблиц.
Для Вас предпочтительнее. Для меня нет. И там не дублирование - элементы заказа разные, семантика разная. То же самое бизнес-знание о типах элементов заказа о котором Вы говорите. Просто выраженное другим способом с меньшим уроном реляционной модели.
Таким образом это не недостаток схемы, которая была приведена ранее:
предложу такую схему, здесь есть избыточности относительно "задачки", и излишество в ключе property_id в таблице product_property(следствие более раннего отсутствия property_value)
но в контексте разговора, здесь нигде нет необходимости составных FK
З.Ы. И я не против выслушать критику и предложения по улучшению структуры
zelenin писал(а): ↑2018.03.16, 19:08
завязав заказ на product, ты теряешь возможность продавать, что-то кроме него, например услугу упаковки подарочной бумагой, комплект продуктов со скидкой 5% или что-то другое принципиально отличающееся от обычного продукта.
Последний раз редактировалось anton_z 2018.03.17, 02:35, всего редактировалось 1 раз.
sm-vasya писал(а): ↑2018.03.17, 02:18
только куда то профи пропал, видимо ждет пока не профи придут к какому то мнению, а он потом придет и скажет "ну я так и хотел написать, только не успел"
Не ну, может он всех удивит и покажет схему объектной базы, которая "идеально вписывается в DDD".
Мне схема samdark нравится. Я бы тоже не увязывал жестко атрибуты категории товара и атрибуты самого товара - слишком накладно. С этой точки зрения хранить атрибуты в jsonb оптимальное и современное решение.
zelenin писал(а): ↑2018.03.17, 02:20
это бизнес-знание - тип лежащей в заказе сущности. Указывает оно на местоположение данных или на специфический обсчет элемента заказа - собственно решать приложению.
А с точки зрения проектирования схем реляционных баз - недостаток.
отсутствие констрейнта - конечно недостаток. но а) это очень академично проектировать базу без знания о приложении б) понятие нормализации тоже является частью проектирования базы - предложенный вами вариант это денормализованная в угоду констрейнтам база.
anton_z писал(а): ↑2018.03.17, 02:32
Для Вас предпочтительнее. Для меня нет. И там не дублирование - элементы заказа разные, семантика разная
ну как же, у элемента заказа нет особой семантики - есть цена, есть количество, есть порождающая сущность. три атрибута. Все остальное - зона ответственности приложения.
sm-vasya писал(а): ↑2018.03.17, 02:18
только куда то профи пропал, видимо ждет пока не профи придут к какому то мнению, а он потом придет и скажет "ну я так и хотел написать, только не успел"
Профи шестичасовой урок за двое суток подготовил и только что провёл. Немного устал.
zelenin писал(а): ↑2018.03.17, 02:43
понятие нормализации тоже является частью проектирования базы - предложенный вами вариант это денормализованная в угоду констрейнтам база.
Какие данные (не метаданные, а именно данные) и где у меня будут дублироваться?
zelenin писал(а): ↑2018.03.17, 02:43
ну как же, у элемента заказа нет особой семантики - есть цена, есть количество, есть порождающая сущность. три атрибута. Все остальное - зона ответственности приложения.
А я думаю есть. "Продукт в заказе", "Услуга в заказе". "Набор в заказе".
Последний раз редактировалось anton_z 2018.03.17, 02:51, всего редактировалось 1 раз.
окей, как всегда дискуссия выливается в спор вокруг несформулированного ТЗ: что надо было придумать схему с максимальной защитой целостности или максимально элегантную и гибкую схему.
sm-vasya писал(а): ↑2018.03.17, 02:18
только куда то профи пропал, видимо ждет пока не профи придут к какому то мнению, а он потом придет и скажет "ну я так и хотел написать, только не успел"
Профи шестичасовой урок за двое суток подготовил и только что провёл. Немного устал.
zelenin писал(а): ↑2018.03.17, 02:51
окей, как всегда дискуссия выливается в спор вокруг несформулированного ТЗ: что надо было придумать схему с максимальной защитой целостности или максимально элегантную и гибкую схему.
Да даже не в этом дело. Я не могу понять, что вы имеете ввиду под "лаконичностью" и "элегантностью" схемы. Понятие не очень технические.
zelenin писал(а): ↑2018.03.17, 02:43
понятие нормализации тоже является частью проектирования базы - предложенный вами вариант это денормализованная в угоду констрейнтам база.
Какие данные (не метаданные, а именно данные) и где у меня будут дублироваться?
zelenin писал(а): ↑2018.03.17, 02:43
ну как же, у элемента заказа нет особой семантики - есть цена, есть количество, есть порождающая сущность. три атрибута. Все остальное - зона ответственности приложения.
А я думаю есть. "Продукт в заказе", "Услуга в заказе". "Набор в заказе".
нет, это просто элемент с тремя атрибутами. разнося элемент по трем таблицам ты искуственно придаешь ему семантику на уровне базы, хотя достаточно того, что семантику будет знать приложение (ведь при добавлении четвертого и пятого типов элементов заказа нам трогать базу не придется).
zelenin писал(а): ↑2018.03.17, 02:55
нет, это просто элемент с тремя атрибутами. разнося элемент по трем таблицам ты искуственно придаешь ему семантику на уровне базы, хотя достаточно того, что семантику будет знать приложение (ведь при добавлении четвертого и пятого типов элементов заказа нам трогать базу не придется).
Ладно, пусть каждый для себя решает. Предлагаю компромисс - это две альтернативных решения, оба со своими преимуществами и недостатками. Принимающий решения должен будет сделать выбор исходя из поставленной задачи.
Последний раз редактировалось anton_z 2018.03.17, 03:02, всего редактировалось 1 раз.
zelenin писал(а): ↑2018.03.17, 02:51
окей, как всегда дискуссия выливается в спор вокруг несформулированного ТЗ: что надо было придумать схему с максимальной защитой целостности или максимально элегантную и гибкую схему.
Да даже не в этом дело. Я не могу понять, что вы имеете ввиду под "лаконичностью" и "элегантностью" схемы. Понятие не очень технические.
но ты конечно читал неоднократно эти эпитеты в технических книгах, лекциях и статьях.
простой понятный код, решающий определенную проблему - в данном случае бесконечную расширяемость без роста схемы БД.
zelenin писал(а): ↑2018.03.17, 03:02
но ты конечно читал неоднократно эти эпитеты в технических книгах, лекциях и статьях.
простой понятный код, решающий определенную проблему - в данном случае бесконечную расширяемость без роста схемы БД.
Не сказал бы, что поддерживаю употребление этих эпитетов в книгах.
Не ну для каждого типа продуктов вы же таблицу будете добавлять? Поэтому не бесконечную.
sm-vasya писал(а): ↑2018.03.16, 17:43
есть витрина в ней товары по категориям. у товара есть название и фиксированные характеристики (например габариты, вес, цена).
есть ЛК пользователя. пользователь видит все свои заказы, счета, акты, сф, платежи и тд. для упрощения берем только 1 документ - например счет. в счете перечислены товары за которые пользователь заплатил, итоговая стоимость
zelenin писал(а): ↑2018.03.17, 02:55
нет, это просто элемент с тремя атрибутами. разнося элемент по трем таблицам ты искуственно придаешь ему семантику на уровне базы, хотя достаточно того, что семантику будет знать приложение (ведь при добавлении четвертого и пятого типов элементов заказа нам трогать базу не придется).
Ладно, пусть каждый для себя решает. Предлагаю компромисс - это две альтернативных решения, оба со своими преимуществами и недостатками. Принимающий решения должен будет сделать выбор исходя из поставленной задачи.
безусловно согласен. проектирование базы - это не сферический конь. У базы есть бэкграунд - приложение и условия его работы. В хайлоаде вынуждены отказываться от констрейнтов, т.к. это сильно оверхедит. В то же время если есть возможность наложить констрейнт без ущерба он должен быть наложен. Ущерб определяет проектирующий.
sm-vasya писал(а): ↑2018.03.16, 17:43
есть витрина в ней товары по категориям. у товара есть название и фиксированные характеристики (например габариты, вес, цена).
есть ЛК пользователя. пользователь видит все свои заказы, счета, акты, сф, платежи и тд. для упрощения берем только 1 документ - например счет. в счете перечислены товары за которые пользователь заплатил, итоговая стоимость
zelenin писал(а): ↑2018.03.17, 03:11
безусловно согласен. проектирование базы - это не сферический конь. У базы есть бэкграунд - приложение и условия его работы. В хайлоаде вынуждены отказываться от констрейнтов, т.к. это сильно оверхедит. В то же время если есть возможность наложить констрейнт без ущерба он должен быть наложен. Ущерб определяет проектирующий.