Складской вопрос

← →
Ломброзо © (2006-10-11 19:20) [0]

Есть некий линейный справочник номенклатуры, который нужно загнать в базу. Позиции связаны между собой черт-те как, но в целом просматривается дерево.
Вопрос: как лучше организовать структуру таблиц: те позиции, которые имеют детей, вынести в отдельную таблицу "Группы номенклатуры", или же запихать все записи в одну таблицу, но для тех записей, которые имеют связь с подчиненными, выставить признак "Группа"?

← →
Ломброзо © (2006-10-11 19:21) [1]

уточнение: данные представлены в виде линейного справочника, но дерево можно выстроить по кодам:
1
1.0 ---
1.0.1 ---
1.0.2 ---

← →
AlexWlad © (2006-10-11 19:34) [2]

create table bla-bla
( id int not null,
id_child int not null,
name char(???)
)

← →
Ломброзо © (2006-10-11 19:40) [3]

> AlexWlad
Это дерево. К тому же неправильно спроектированное :) Вместо id_child должно быть id_parent, раз уж мы строим дерево.

← →
Sam Stone © (2006-10-11 19:41) [4]

Загоняй так, чтобы потом самому было удобно работать )

← →
vidiv © (2006-10-11 19:43) [5]

> Ломброзо © (11.10.06 19:40) [3]

дерево лучше всего организовать с помощью "Теории вложенных множеств". В инете есть описание, и даже примеры (на PHP + MySQL точно)...

Лично использовал для построения дерева на собственном форуме :)

← →
Ломброзо © (2006-10-11 19:46) [6]

Я полагаю, для того, чтобы построить дерево на форуме можно обойтись и без теории :) а вот чтобы в рекурсию не впасть, наверное стоит с ней ознакомиться, хотя бы тезисно :\

← →
Ломброзо © (2006-10-11 19:50) [7]

> vidiv © (11.10.06 19:43) [5]
Спасибо, нарыл на SQL.ru
http://sdm.viptop.ru/articles/sqltrees.html

Но вопрос о практической реализации задачи остаётся открытым )

← →
vidiv © (2006-10-11 19:50) [8]

> Ломброзо © (11.10.06 19:46) [6]

в том то и дело, что рекурсия тут не требуется =))) обсалютная линейность =)))

← →
vidiv © (2006-10-11 20:00) [9]

> Но вопрос о практической реализации задачи остаётся открытым
> )

я думаю, следует более корректно задачу поставить...
Если уровней дерева всего два: группы и элементы - то лучше две таблицы ИМХО

← →
Ломброзо © (2006-10-11 20:05) [10]

нет, всё гораздо хуже. Я все-таки имею дело с графом.

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

Но сложные медицинские услуги могут включать в себя как простые, так и сложные, причём отношением многие-ко-многим ) Если представить себе, что нам нужно посчитать стоимость сложной услуги А, которая включает в себя сложную услугу Б, которая в свою очередь через пару связей снова ссылается на А, то...

← →
vidiv © (2006-10-11 20:13) [11]

> Но сложные медицинские услуги могут включать в себя как
> простые, так и сложные, причём отношением многие-ко-многим
> ) Если представить себе, что нам нужно посчитать стоимость
> сложной услуги А, которая включает в себя сложную услугу
> Б, которая в свою очередь через пару связей снова ссылается
> на А, то...

это уже не дерево, и цена будет равное бесконечности, если, конечно, вообще будет =)

← →
PEAKTOP © (2006-10-11 20:24) [12]

http://delphimaster.net/view/3-1160041068/
Смотри пост № PEAKTOP © (05.10.06 16:47) [16]

← →
Суслик © (2006-10-11 21:30) [13]

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

← →
Petr V. Abramov © (2006-10-11 22:06) [14]

> но для тех записей, которые имеют связь с подчиненными, выставить признак "Группа"?
1. СУБД?
2. из общих соображений - все в иерархию, инече ифиов не оберешься, где не ждал

← →
kaif © (2006-10-11 22:28) [15]

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

Для начала я лично построил бы дерево. И посмотрел бы потом на него глазами, пытаясь ответить себе на вопрос, что потеряет юзер, если ограничить все дерево тремя "уровнями"? Если вижу, что ничего не потеряет, то обойдусь без всяких деревьев. Если же увижу, что все здесь довольно неоднородно, есть и крупные, многоуровневые ветви и очень короткие, то буду думатьв направлении дерева и постоянно возвращать заказчика к вопоросу об отчетах: ЧЕГО ОН СОБСТВЕННО ХОЧЕТ ОТ ОТЧЕТОВ? Если ничего не хочет - тогда дерево. С голубой каемочкой.

← →
kaif © (2006-10-11 22:30) [16]

2 Petr V. Abramov © (11.10.06 22:06) [14]
Тебе хорошо говорить. А если у человека не ORACLE? Так он потом с деревом потом геморроя не оберется в SQL-запросах.

Нужно сначала про сервер разузнать.

2 Ломброзо ©
Какой сервер-то?
Если ORACLE - слушай Петра.
Если нет - слушай меня.
:)

← →
kaif © (2006-10-11 22:44) [17]

Хотя нет.
Никого вообще не слушай.

Сделаешь поля - будешь сам тащиться от отчетов.
Сделаешь дерево - тащиться будет юзер.

Выбирай, что для тебя важнее.

Я сам сейчас перед такой точно дилеммой.
Я уже сделал дерево.
И кучу поддержки к нему.
И лдаже интерфейс.
Хочу сломать это все нафиг.
Вот уже два дня не работаю.
Только на форуме и треплюсь.
Уже сделал бы заново и сломал бы заново несколько раз.
Возможно даже остановился бы на чем-нибудь.
Не знаю...
В общем.
Давай лучше холивар устроим: дерево или таблица? Я - за таблицу и виселицу для юзера на дереве. Хочет дерево - виселица во дворе. Милости просим.
:)

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

Если же это что-то неоднородное (мухи и котлеты), то я стараюсь сделать отдельно таблицу для мух, отдельно - для котлет. Если нужно объединять, еще одну таблицу - "общее между мухами и котлетами" или "общий журнал живности", в который вписываю еще раз те же ID из двух таблиц. Пространство ID стараюсь сделать глобально уникальным.

← →
Ломброзо © (2006-10-11 23:05) [18]

> Все зависит от того, какие в дальнейшем предполагаются отчеты.
Отчетов с группировками по ветвям дерева я перестал бояться на прошлой неделе, когда хорошенько ковырнул Microsoft Reporting Service - он отлично строит деревья, и группирует, и суммирует так и сяк по скормленной плоской таблице, в которой присутствуют идентификаторы родительской и подчинённых записей.

>1. СУБД?
У меня ORACLE! ) он спасёт отца русской демократии? Что там нужно почитать, чтобы для пяти уровней вложенности пять раз одну и ту же таблицу саму с собой не связывать? <offtop к теме полугодовой давности: Oracle XE 10 на ноутбуке с 760 мб (было 256) озу отлично себя чувствует>

> некоторый однородный континуум:
Континуум-то достаточно однородный, но в реляционную модель тяжело утрамбовываемый. В ООП все просто: номенклатура - абстрактная сущность, ID, NAME, единица измерения. От неё растут наследники - лекарства, услуги и т.д. - и всяк потомок имеет дополнительные атрибуты. Так что приходится параллельно воевать и с деревом, и с имитацией наследования.
Я воспользовался советом Суслега и все связи сделал многие-ко-многим. На первый взгляд структура получается достаточно изящной.
Буду думать, как предупредить зацикливание связей.

← →
kaif © (2006-10-12 00:19) [19]

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

← →
Ломброзо © (2006-10-12 00:29) [20]

Пока суть да дело, получилось вот что (неинформативные поля не привожу)

1. Базовый справочник номенклатуры (ID, PARENT_ID, NAME) - завязан сам на себя -> дерево
2. Справочник номенклатуры медуслуг - "расширяет" базовый справочник номенклатуры (связан с ним 1:1) (ID, CODE)
3. Таблица связей многие-ко-многим таблицы №2 - для группировки _только_ услуг (PARENT_ID, CHILD_ID)

То есть получается, что таблица 2 как бы наследует таблицу 1, а для того, чтобы можно было работать с обеими таблицами аки с одной, я смастерил представление и навесил на него триггеры instead of, в которых раскидываю данные в ту или иную таблицу.

Самое главное - чтобы никто не лазил в таблицы в обход представления.

Аллес, всем спасибо :)

← →
Sergey13 © (2006-10-12 08:53) [21]

> [20] Ломброзо © (12.10.06 00:29)

Достаточно 2 таблиц. См
> [12] PEAKTOP © (11.10.06 20:24)

> У меня ORACLE! ) он спасёт отца русской демократии?
Конечно. Ищи в справке CONNECT BY

← →
Sergey13 © (2006-10-12 08:57) [22]

> [20] Ломброзо © (12.10.06 00:29)

В дополнение к
> [12] PEAKTOP © (11.10.06 20:24)

первая таблица может так-же иметь деревянную структуру. Плюс, для производительности, я делал дплнительное поле с указателем на рутовую запись (чтобы строить дерево только по нужным записям, ибо деревянные запросы достаточно тормозные на приличных объемах).

← →
evvcom © (2006-10-12 12:50) [23]

> [22] Sergey13 © (12.10.06 08:57)
> ибо деревянные запросы достаточно тормозные на приличных
> объемах

Точнее, наверное, все же "на приличном количестве уровней", хотя, конечно, и объемы дают о себе знать.

Кстати, кто-нить знает, можно ли в оракловом деревянном запросе заставить оптимизатор выбрать HASH JOIN метод?

← →
Sergey13 © (2006-10-12 13:13) [24]

> [23] evvcom © (12.10.06 12:50)

> Точнее, наверное, все же "на приличном количестве уровней",

Ну не знаю. Я помню долго пытался ускорить выборку полной ветки в тригере из деревянной таблицы где-то на полмиллиона записей. Крутил-вертел и в конце концов сделал как написал. Время выборки сократилось примерно на 2 порядка.

← →
MsGuns © (2006-10-12 13:37) [25]

Ребята, а вы не путаете деревья с графами, как РЕДАКТОР ?

← →
evvcom © (2006-10-12 14:07) [26]

> [24] Sergey13 © (12.10.06 13:13)

А я и не отрицал влияния большого объема. Но если, допустим, дерево будет иметь уровней 10 вложенности, то и на 1000 записей это будет весьма заметно. Сталкивался с этим давно, потому особо спорить не буду. Может я и не совсем прав.

> [25] MsGuns © (12.10.06 13:37)

Я не путаю. Но я про графы и не заикался. С графами 2 таблицы, одна - вершины графа, другая - связи. Каких-либо особых конструкций ораклового SQL для графов я не знаю. Видимо, их нет. :)

← →
ANB © (2006-10-12 14:26) [27]

Внесу свое имхо.

Возьмем для примера справочник товаров. После всяких вариантов я пришел к выводу, что оптимальнее всего сами товары хранить в отдельной плоской таблице (заведя поле группы). Группы товаров - еще в одной деревянной парентовой таблице (ID, Parent_ID, Name . . .). Если товары связаны между собой (например, комплектующие, которые могут продаваться как с основным аппаратом, так и отдельно), то можно добавить линковку. Нестандартные атрибуты по желанию выносятся в четвертую таблицу.

Преимущества :
1) возможность завсегда построить отчет или поискать товар по группам
2) возможность работать с плоским списком товаров (по алфавиту) - иногда удобнее.
3) не путаются группы и сами товары (у них разные атрибуты)

Оракл позволяет легко работать с деревьями. Один минус - если захочешь проверять на всякий случай попытки зациклить дерево в триггере - придется обходить мутацию.

← →
Sergey13 © (2006-10-12 14:54) [28]

> [26] evvcom © (12.10.06 14:07)
Да я тоже на своей исключительной правоте не настаиваю. 8-)
Я мыслю так. Если не ограничить выборкой построение дерева, то Оракл будет каждую запись искать по всей таблице. Даже по индексу это наверное накладно, ибо ищет-то он последовательно, а не скопом. А ограничивая выборку (читай записывая ее в память) прокрутить даже 1000 (в моем случае было редко больше 200, а вложенностей было до 15-20 уровней - спецификация) записей в ветке ИМХО быстрее.

Это мои наукообразные умозаключения не имеющие под собой никакой основы, кроме личной практики. 8-)

← →
ANB © (2006-10-12 14:59) [29]

> Но если, допустим, дерево будет иметь уровней 10 вложенности,
> то и на 1000 записей это будет весьма заметно. Сталкивался
> с этим давно, потому особо спорить не буду. Может я и не
> совсем прав.

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

← →
ANB © (2006-10-12 15:01) [30]

я писал обход ветки дерева на клиппере. получилось все на индексах (и быстро работает). те же самые индексы создаешь в оракле - и он тоже шустро работает. Тащить все на клиента и фулл-сканом сортировать - медленно и некрасиво.

> Ломброзо © (11.10.06 19:21) [1]
> уточнение: данные представлены в виде линейного справочника,
> но дерево можно выстроить по кодам:
> 1
> 1.0 ---
> 1.0.1 ---
> 1.0.2 ---

Налицо 3 уровня - значит двумя таблицами не обойтись.
Это простая рефлексирующая связь таблицы самой на себя. У меня в любом проекте в БД таких по 10% как минимум. Это и бух.баланс (не кредитный), это и справочник товаров и дофига еще чего подобного.
Все описанные выше геморрои связаны только с неистребимым желанием исполнить логику на ХП. Да и то особых проблем не вижу. Оракловый запрос "connect ... by ... prior" помогает, но не является панацеей.
Только надо ответить на один очень важные вопросы "Зачем это надо? Заказывал ли это клиент? Облегчит ли это работу, а если усложнит, то насколько?"

>Курдль © (12.10.06 15:14) [31]
>Налицо 3 уровня - значит двумя таблицами не обойтись.

У меня в базе "Состав заказов" графы до 12 уровней вложенности каждый. Сколько мне надо таблиц ?

> MsGuns © (12.10.06 15:26) [32]
> У меня в базе "Состав заказов" графы до 12 уровней вложенности
> каждый. Сколько мне надо таблиц ?

А что за база и скока платишь за анализ профайлинг? :)

> Сколько мне надо таблиц ?

одна.

> ANB © (12.10.06 15:35) [34]
> > Сколько мне надо таблиц ?
> одна.

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

>Курдль © (12.10.06 15:32) [33]
>А что за база

Ты копи-пасте жмякаешь не глядя ?

>анализ профайлинг? :)

Тебе никто не намекал на излишнюю любовь к заворачиванию простых мыслей в сложные наряды ?

> MsGuns © (12.10.06 15:50) [36]

Я, как и подобает участникам обсуждения, продолжал общую мысль, опираясь на предыдущие посты.
В частности, на:

vidiv © (11.10.06 20:00) [9]
> я думаю, следует более корректно задачу поставить...
> Если уровней дерева всего два: группы и элементы - то лучше две таблицы ИМХО

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

> , требующая исключительных мер поддержки
> целостности данных?

На одной все можно организовать.

ANB © (12.10.06 16:08) [38]

Да можно вообще любую БД на одной таблице организовать.

Id, Name(string) и Value(string)

:)

> ANB © (12.10.06 16:08) [38]
> На одной все можно организовать.

Да, этот прикол на каждом цикле обучения по ораклу показывают:
одна сущность с рефлексирующей связью под названием "весь мир"
:)))

> Ломброзо © (11.10.06 20:05) [10]
>
> нет, всё гораздо хуже. Я все-таки имею дело с графом.
>
> Вообще речь идет о номенклатуре медицинских услуг, которые
> подразделяются на простые и сложные.
> И простые медицинские услуги, и сложные можно организовать
> в дерево.
>
> Но сложные медицинские услуги могут включать в себя как
> простые, так и сложные, причём отношением многие-ко-многим
> ) Если представить себе, что нам нужно посчитать стоимость
> сложной услуги А, которая включает в себя сложную услугу
> Б, которая в свою очередь через пару связей снова ссылается
> на А, то...

Разбить все на атомарные подуслуги(возможно даже технические, невидимые пользователю) и загружая в память каждую услугу при обходе графа маркировать подуслугу, чтобы не включить лишнее, попутно составляя массив указателей на включенные подуслуги. Далее посчитать массив подуслуг.

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

А по русски можно?

> В ООП все просто: номенклатура - абстрактная сущность,
> ID, NAME, единица измерения. От неё растут наследники -
> лекарства, услуги и т.д. - и всяк потомок имеет дополнительные
> атрибуты. Так что приходится параллельно воевать и с деревом,
> и с имитацией наследования.

Так может?
http://www.db4o.com/

Складской вопрос Найти похожие ветки