Как правильно спроектировать БД?

Question

[Максим Гречушников]

Тема следующая:
Надо сделать базу данных, в которой будут сети магазинов, в этих сетях есть магазины. Магазины в конкретных городах. В СЕТЯХ (не в магазинах) есть товары, например, молоко. Но молоко может быть ОАО Залесский фермер или ОАО ЕЖК. В разных сетях товар разных вендоров стоит по разному. Помимо этого в одной сети в разных городах может стоить по разному товар...
Встал вопрос как правильно хранить цену в базе, так чтобы было не сложно вытаскивать ее потом запросами.
Усложняется все тем, что товар не товар. То есть товар нужно делать SKU. Поэтому цена будет зависеть от параметров товара. Я привел пример базы с конкретным товаром, и что то не могу продумать схему "товары с SKU"

Плюсом нужна история по датам

Comments

[Макс]

А зачем в price дата? время начала действия цены? тогда что есть окончание? новая цена для того-же SKU?

[Максим Гречушников]

Mr. Robot: если вам сложно можете идти лесом. все тут за свои вопросы как то косвенно получают деньги. я не прошу сделать, прошу совета.

[Максим Гречушников]

Макс: да, дата начала действия. конец не предусматривал. думал просто вытаскивать последнюю цену

[Максим Гречушников]

Mr. Robot: во первых, вы в своем уме? я ничего ни у кого не украл. во вторых, сюда идут за советами, так же как и я, и эти советы прямо или косвенно касаются заработка топикстартера. в третьих, "ПОВТОРЮСЬ", если вам сложно и жалко времени, лес прямо. да я хам, но если не можешь помочь иди своей дорогой.... или в лес... нечего тут устраивать разборки. у кого есть возможность помогут. когда сам решу задачу, тогда и выложу ответ. и я не первый и не последний с таким вопросом на этом ресурсе.

[Максим Гречушников]

avtomarket.ru/stuff/trash/00/295004_bg4n9e05vh_130...

[Макс]

Mr. Robot: "а во вторых никто здесь не получает ни копейки!" - ну почему, здесь куча вопросов на рабочие темы. Я сам задавал такие вопросы - и мне помогали. И я не раз отвечал на явно не любительские вопросы. Вас напрягает, что человек просит помощи? Вы зря посещаете это ресурс, здесь 90% просит помощи.

[Макс]

Mr. Robot: "Терпеть не могу попрошаек." - сложно отнести к коллеге. его вклад в Тостер почти втрое выше Вашего. так что совета он уж точно заслужил. Тем более что ситуация как раз вполне нормальная - человек силен в разработке, но не гуру в архитектуре БД. А уж считать чужие деньги - вообще только карму себе портить.

[Максим Гречушников]

вот у человека пукан рванул, что ему кусок не достанется... п.с. мне с этого кроме зп тоже ничего не перепадет.

Answer 1

[vladz]

Вы ещё в постановку добавьте различного рода игры с ценами: акции, скидки, миксы... ну лояльность до кучи. Тему терминалов или точек продаж нужно тоже раскрыть, а то переделывать потом..

Comments

[hrum]

ага, исходя из моего личного опыта, это все равно придет, пусть не сразу, но через год-другой точно. ;)

[vladz]

hrum: если это курсовик, то можно поскипать. Если нечто для бизнеса, то решение будет совершенно неконкурентно. Бизнес будет проигрывать конкурентам... Расправа над тыжпрограмистом неизбежна ;)

Answer 2

[Алексей Ostin]

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

То есть, цена будет объединять товар (Items), магазин (stores), свойства товара (?). Получить цену в конкретном магазине - 1 джоин. Получить все цены одного товара - простой запрос по индексу.

Выложите MWB-проект, чтобы было проще.

Comments

[Алексей Ostin]

Перечитал задание, вместо магазина получается сеть + город.

[Макс]

Максим Гречушников: нужна история по датам - введите и дату окончания действия цены, проще искать будет.

Answer 3

[Евгений Безымянников]

А как цена высчитывается?

Comments

[Максим Гречушников]

никак. только руками вставляется

[Максим Гречушников]

что то вроде справочника планируется

[Евгений Безымянников]

Максим Гречушников: ну тогда для каждого scu|города|сети отдельная запись

Answer 4

[heartdevil]

Привет.

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

Мне кажется все равно основной единицей у вас должен быть товар, а не цена. А цена должна быть у типа товара.

Comments

[Максим Гречушников]

тип товара увы это лишь - молочная продукция, сыпучие, крупы, алкоголь.
а цена у конкретного товара. Молоко 900мг 2,5% жирности от ОАО МОЛОКО в сети магазинов Звездочка в городе Крыжупль.

[Максим Гречушников]

то есть как видим, у нас имеется сам товар и его SKU атрибуты: обьем, жирность, вендор, сеть маг., город
и вот от этих параметров (а их может быть и больше) зависит цена.

[Макс]

Максим Гречушников: imho SKU у Вас - это запись в таблице price. т.е. SKU - это сумма товар+сеть+город.
к ней справочник с товарами, сетью и городом. "Вендор" - свойство товара (это если хотите заполнять отдельно. Вторая форма, конечно, требует - но оно Вам надо?).

Answer 5

[sasha]

Если вам нужна история цен по датам то пожалуй докиньте дату в первичный ключ(или уникальный) в таблице price. а если вам нужен SKU каждого товара то вместо item_id в prices можете использовать SKU, который в свою очередь будет ссылаться на нужный item_id

Answer 6

[Михаил Гаврилов]

А вам параметр сеть для чего-то конкретно нужен?
Если нет, то можно все представить точками продаж, у каждой точки продажи есть адресс, контакты, ну и свое юр. лицо владелец. А цена это всеголишь витрина, которая для каждой точки продажи своя. Вот только если у вас точки продажи несвязанные (у каждого магазина своя биза 1C с номенклатурой причем ID номенклатуры между магазинами не пересекаются), то и номенклатура должна быть у каждой своя. и еще молоко в точке продажи 1 <> молоко в точки продаже 2 потомучто срок годности другой или производитель итд.

Answer 7

[Devman Po]

Можно пойти от заведения Типов Цен. Есть товарная позиция - Молоко (оно и в Африке - Молоко), есть "опции" Молока, в данном случае: "Производитель", "Процент жирности" и тп.

Заводим "Тип цены" - "Базовый". который может просто рассчитываться из закупочной. Далее заводим другие типы цен (Точки, Сети, Филиалы, "Цены для магазина в Бобруйске" и т.п.) Важная характеристика Типа цены - правило расчета - динамическая или на основании другой цены + фиксированный процент (или любой другой алгоритм) - суть правила расчета - назначить/рассчитать цену по входящим данным, как то: Товар, его опции, точка сети и т.д.

Для каждого товара свой тип цены, в зависимости от опций и/или сетей - для товара (а с опциями - это уже SKU) назначается определенный/свой тип цены для его расчета.
Это вкратце)
ЗЫ думаю, важный момент иметь общую НСИ для всего ИТ поля. И даже если в каждом магазине своя база и "свой id номенклатуры" - необходимо внедрить общий реквизит для их синхронизации. Это касается и "типов цен" и "правил расчета цен"