|
|
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
Коллеги, помогите советом плиз, опыта проектирования мало, сломал себе уже весь мозг. Вкратце так: 3 основные таблицы Таблица 1 - список наименований товаров, к примеру молоко, кефир, йогурт и т.д. [связь с Т2 один ко многим] Таблица 2 - товары с формой выпуска, к примеру кефир 1% в тетрапаке, кефир 3% в пакете и т.д. [связь с Т3 один ко многим] Таблица 3 - физически существующие в природе товары с их производителями. (производители в отдельной таблице) идем дальше в каждой таблице товары разбиваются на группы, классификатор организован в виде отдельной таблицы, для удобства в виде дерева (id, parent, name) и вспомогательной таблице для организации связей много ко многим. и вот тут 2 принципиальных вопроса: 1. имеет смысл городить огород из 3-х таблиц ? или проще запихать все в одну таблицу, но с бОльшим количеством полей, ну и соответственно будем много повторяющихся значений ? 2. на каждую таблицу с товарами создавать отдельную таблицу с классификаторами ? или сделать всего одну таблицу для классификации, а в select - ах, джоинить товары из таблиц 1, 2 и 3 уже в зависимости от самого классификатора, т.е. переносить частично на логику работы приложения заранее благодарен за помощь !!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2015, 03:44 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
вопрос от печки: кому-то интересно будет анализировать сколько кефира 3% продалось? или просто тупо за оборот "общей молочки" будут интересоваться? вот тут и выбор будет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2015, 11:24 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
Лучший вопрос на sql.ru за последние ~пять лет, спасибо. > сломал себе уже весь мозг Ничего удивительного. Задача сложнее, чем кажется на первый взгляд. Вы можете выбрать два способа рассуждений: "как надо" и "чем реально пользуются". Чем реально пользуются обсуждать не интересно: как правило, это тупые примитивные решения. > товары с формой выпуска Играют роль и другие факторы. Продукты, выпущенные по ГОСТ и ТУ - разные продукты, даже если у них совпадают названия, технологические характеристики и фасовка. В чём плюсы детализации структуры: вы можете использовать аналитику. Например, корректно посчитать инфляцию по разным продуктам или группам продуктов. Например, оценить влияние изменение цены базового продукта на цены производных продуктов. Например, оценить влияние законодательных инициатив на цены. В чём минусы: трудоёмкость поддержки базы данных. То, что продаётся в магазинах под названием "молоко" в подавляющем большинстве случаев должно в соответствии с российским законодательством называться "молочный напиток". Т. е. дополнительно к основной задаче вы получаете достаточно объёмную задачу сопровождения, не говоря о том, что вам придётся использовать виртуальные название и формально корректные одновременно. Другими словами, вам нужно сначала ответить себе на вопрос, какую именно задачу вы решаете. Здесь дело даже не в ТЗ, а в общей идеологии продукта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2015, 16:07 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
понятно что надо начинать с постановки задачи, требованиям к конечному продукту и т.д. частично это есть, но в достаточно общих формулировках и что-то мне подсказывает что конечный результат может сильно отличаться от того что сейчас "хочется" в общем думаю как бы переделывать потом по минимуму.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2015, 18:38 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
> понятно :) Не думаю. В данном случае для вас существенно то, что сложность хорошего решения будет на порядки выше того, что есть на рынке. Я привёл тривиальный фрагмент частной подзадачи, - таких подзадач будет много. Очень много. Тем больше, чем большее количество рынков вы будете рассматривать. > думаю как бы переделывать потом по минимуму Зафиксируйте максимально детально требования к идентификации людей, предприятий и продуктов. Это позволит избежать ненужной работы. Сложно давать рекомендации, не зная вашей квалификации, ваших целей и ваших задач. Любая база данных - компромисс между тупоголовостью заказчика, бюджетом, сроками и пр. Куча ограничений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2015, 19:12 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
На мой взгляд я бы сделал одну таблицу (Таблица 3) а таблицы 1 и 2 это просто справочники (наименований товаров и форм выпуска, причем не связанных между собой) rawman для удобства в виде дерева (id, parent, name)А вот это не стоит. Такая структура делает возможным бесконечное добавление уровней, требует поддержки иерархических запросов для СУБД, сами запросы труднее для восприятия, но при количестве уровней больше пяти-семи уже неудобно пользоваться. Делайте нормальные статические категории, подкатегории, подкатегории второго уровня и т.д. Второй принципиальный вопрос мне непонятен совсем. У вас разные наборы полей для разных товаров? Ищите по форуму по слову наследование - есть реализации с одной, двумя и тремя таблицами. У каждой есть свои достоинства и недостатки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2015, 19:15 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
rawman3 основные таблицы Таблица 1 - список наименований товаров, к примеру молоко, кефир, йогурт и т.д. [связь с Т2 один ко многим] Таблица 2 - товары с формой выпуска, к примеру кефир 1% в тетрапаке, кефир 3% в пакете и т.д. [связь с Т3 один ко многим] Таблица 3 - физически существующие в природе товары с их производителями. (производители в отдельной таблице) 1) Товары — это только «физически существующие в природе товары» (табл. 3), только у них и могут быть производитель, «форма выпуска» и т.п. В зависимости от задачи «жирность» и подобные свойства могут быть отнесены как сюда, так и к категории в целом. 2) «Список наименований товаров, к примеру молоко, кефир, йогурт» (табл. 1) — это кусок классификатора, т.к. «молоко», «кефир» и «йогурт» суть названия групп/категорий внутри «молочной продукции». Табл. 2 в таком виде не нужна вообще (иначе получите «Рубашка / муж. хлопок Турция Синяя / р. 52» как здесь 16717416 ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2015, 00:32 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
rawman1. имеет смысл городить огород из 3-х таблиц ? или проще запихать все в одну таблицу, но с бОльшим количеством полей, ну и соответственно будем много повторяющихся значений ? Я за 1й вариант. Потом выкладывайте сюда, посмотрим что получилось ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2015, 22:32 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
rawman, я бы рекомендовал разделить таблицы для хранения данных и таблицы для аналитических задач, в которые данные наполняются из таблиц хранения. проведите GAP-анализ. Возможно, возникнут такие понятия как партии, упаковки, комплекты, производители и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2015, 00:19 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
всем спасибо за помощь. кому интересно, посмотрите что получилось, покритикуйте.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 16:00 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
rawman, Добрый день. Вообще задача классическая для DWH розничной сети :) но не буду снобом. Перво наперво, необходимо определить логическую модель под бизнес потребность. Для чего вы будете использовать эту модель? если для OLTP то подход должен быть один, если для аналитического хранилища то другой. Вторым делом необходимо определиться могут ли свойства меняться во времени, допустим один и тот же товар могли поставлять несколько разных поставщиков. Или производитель поменял объем с 1 литра молока на 0,9. Если свойства будет меняться и вы не хотите каждый раз генерить новый ключ для товара (партионный учет) то необходимо вводить понятие периода действия (с - по). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2015, 17:39 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
ams_ar Или производитель поменял объем с 1 литра молока на 0,9. Если свойства будет меняться и вы не хотите каждый раз генерить новый ключ для товара (партионный учет) то необходимо вводить понятие периода действия (с - по). А придется! (с) :) Если Вы закупили 1000 пакетов молока по 1 литру, продали 700 и 300 осталось на складе, а на следующий день производитель привозит уже пакеты по 0.9 - непонятно как Вам помогут периоды действия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2015, 17:51 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
Кот Матроскинams_ar Или производитель поменял объем с 1 литра молока на 0,9. Если свойства будет меняться и вы не хотите каждый раз генерить новый ключ для товара (партионный учет) то необходимо вводить понятие периода действия (с - по). А придется! (с) :) Если Вы закупили 1000 пакетов молока по 1 литру, продали 700 и 300 осталось на складе, а на следующий день производитель привозит уже пакеты по 0.9 - непонятно как Вам помогут периоды действия. согласен. можно формировать ключ преломления свойства товара (item_dtl = item||dt_from||dt_to) и рядом держать родительское свойство товара item. В итоге должно получиться примерно следующее: Item - товарный справочник с дочерним и родительским ключом (+ описание и свойства не зависящие от поставщика) Supplier - справочник поставщиков Item_Supplier - справочник товаров поставщика (item_dtl, supp_id, + свойства жирность, количество в упаковке и т.д) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2015, 18:03 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
производитель поменял объем с 1 литра молока на 0,9Хотите вы или нет, но это уже другой товар . Тот же самый товар, это когда слегка меняется этикетка и/или новый штрихкод. Без изменения объема, названия и свойств упаковки. Даже одинаковый кетчуп дой-пак с дозатором (дп/д) и без дозатора(дп/бд) это уже разные товары. Увы. У них разный спрос и разная цена. Даже сырок "Дружба" одного и того же завода может быть разным товаром(!), т.к. этикетки разные (а-ля СССР и современная) и спрос на них совершенно разный . Таковы предпочтения покупателя и Вы с этим ничего не поделаете. Аналогично акция с подарочным "прицепом" на скотче. Это может быть другой товар. К тому же требующий отдельной маркировки, чтоб не путать на кассе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 10:14 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
LSVпроизводитель поменял объем с 1 литра молока на 0,9Хотите вы или нет, но это уже другой товар . Тот же самый товар, это когда слегка меняется этикетка и/или новый штрихкод.Не всегда так. Бывает, что объем меняется при полном сохранении всего остального, в т.ч. штрихкода. А по документам товар неотличим от предыдущей поставки. И об изменении узнаешь не от поставщика, а только когда новый товар на полках расставлять начинаешь. Причем местный менеджер поставщика может даже не знать об этом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 11:20 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
в представленной схеме так называемое ядро справочников, движение товара и партии это следующий шаг. авторДаже сырок "Дружба" одного и того же завода может быть разным товаром(!), т.к. этикетки разные (а-ля СССР и современная) и спрос на них совершенно разный. Таковы предпочтения покупателя и Вы с этим ничего не поделаете. это тоже предусматривает текущая структура. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 15:52 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
miksoftНе всегда так. Бывает, что объем меняется при полном сохранении всего остального, в т.ч. штрихкода. А по документам товар неотличим от предыдущей поставки. И об изменении узнаешь не от поставщика, а только когда новый товар на полках расставлять начинаешь. Причем местный менеджер поставщика может даже не знать об этом.Бывает и такое, хотя это лютая дикость. :) Если остатки пересекаются, т.е. в наличии оба вида, то выход один - маркировать одну из карточек. Обычно с меньшим остатком. В других случаях (остатки не пересеклись) можно просто переименовать карточку. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 15:53 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
rawmanэто тоже предусматривает текущая структура.Структура в стартовом топике - мертворожденная. Долго рассказывать, почему. Ее трудно поддерживать актуальной и трудно вести отчетность и аналитику. Имейте ввиду, что карточек будет неск. сотен тыс. Малейшее усложнение сделает работу аналитиков и отдела закупок настоящим адом. А еще Вам стоит открыть для себя производство: пекарня, салаты, мясо и пр. Во де будет веселуха. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 16:01 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
LSV, авторСтруктура в стартовом топике - мертворожденная. не соглашусь про аналитиков, у них как раз проблем не будет. действительно будет дополнительная трудоемкость при заведении новых товаров, но зато будет порядок. примерная оценка максимального кол-ва товаров составляет 500тыс. к примеру сейчас работает система в которой все проще и это породило кучу других проблем как раз для аналитиков (куча задвоенных позиций, проблема с производителями, отдел закупок просто умирает и т.д.), нанятые на аутсорсе операторы решают частично проблему, но не на 100%. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 17:46 |
|
||
|
проектирование классификатора товаров
|
|||
|---|---|---|---|
|
#18+
авторкуча задвоенных позиций, проблема с производителями, отдел закупок просто умираетНиодна система не устранит эту проблему, т.к. это на 100% человеческий фактор. Всегда есть возможность накосячить/натупить/поломать. Разные специалисты могут разойтись во мнении, как организовать карточки для некот. товаров. Более простая схема будет в выигрыше, т.к. она требует меньше телодвижений и мозговых усилий. зы: принимал косвенное участие в сведении в единую базу примерно 12 магазинов. В сумме ок. 400тыс. артикулов. В итоге получилось ок. 60 тыс. Огромная работа целого отдела в теч. неск. месяцев (работа магазинов не прекращалась). Самое главное - наладить максимально строгий, но при этом простой для понимания, формализованный процесс. Программки и таблички - вторичны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 10:54 |
|
||
|
|
start [/forum/topic.php?fid=32&fpage=23&tid=1540633]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
46ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
| others: | 14ms |
| total: | 163ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
