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

для реализации такой задачи можно например сделать 2 таблицы:
табл Companies: ID|ClientID|DateBegin|DateEnd|CompanyNeme|DopInf - таблица рекламных компаний
и таблицу Orders: ID|CompanyID|DateBegin|DateEnd|DopInf

и вродебы проблем никаких... но если наша фирма например захочет продавать компьютеры...
или ещё чтото составное,

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

У меня имеется следующая идея:
обобщённая таблица для всех заказов:
Orders:
ID|OrderKind|OrderType|ClientID|DateBegin|DateEnd|OrderName|OrderID|DopInf

OrderKind - вид заказа = {основной пакет, пакет, единичный заказ}
OrderType - просто тип заказа(основного пакета, или пакета) - нужен для того чтобы по типу
подключать - доп таблицы аттрибутов, и для бизнеслогики...

для отображения цен нужно будет во вьюхе указать например процедуру
getPrice(OrderID) - которая в зависимости от вида заказа или возвращает price, если это
единичный заказ, или результат подсчёта суммы рекурсивной функции на pl/sql...

я подобных задачь ещё не решал, поетому неуверен в правильности структуры, посоветуйте как
нужно работать с заказами ?
спасибо.

DogenКлиенту тоже будет очень любопытен алгоритм расчета цены на комплект услуг.
Вы его покажете клиенту, или скажете что мы секретов таких не раскрываем?

"пока вы смотрите свой телевизор, инопланетяне через него трахают вам мозги"

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

ID|ServiceTypeID|ServiceName|ServiceID|DopInf
- т.е. это так же иерархический рекурсивный справочник...
т.е. например может выглядеть так:
. услуги
.. размещение реклммы
.... разм рекламы на к-ях
...... фармабоксы
...... Фармафреймы
...... Фармалайты
...... Ситилайты
...... Фармастенды
.. разм выкладок
.Товары
.. Мебель
но это всего лиш справочник... и внём ничего непонятно про цены...

а чтобы сформировать цены, нужно сформировать ещё 1 справочник...
справочник затрат - такойже как и справочник товаров и услуг примерно...

а после эээтого... нужно привязать затраты к услугам таблицей many to many....

но ещё услуги могут быть затратами для других услуг, т.е. эта many to many должна быть непростая а модная какая то, или затраты и услуги нужно обьединять...

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

неужели действительно всё так сложно... ??????
посоветуйте основываясь на опыте как это всё можно организовать и систематизировать?

Kartas TurboMutanttraktor123
А в чем преимущество этой мегатаблицы? Чем плох вариант с 2-мя таблицами - в одной - заказы, в другой, что туда входит?

а и надо так делать. с двумя таблицами. у меня в схожей системе вообще три - "Даты" "Заказы" и "состав заказа". из соображений поддержания целостности. инфа хранится за 3 последних месяца. которая старее - в архив.
а если заказ будет не 2-х уровневый а 4-х уровневый, например
Партия блоков
блок1
блокN
Монитор
Компьютер
Корпус
Материнская плата
память
кулер
....

как тогда ваши 3 таблицы этот заказ обработают, если учесть что нужна возможность именно такой детализации ?

и ещё...
у вас инфа хранится 3 месяца, потом в архив:
1. а что представляет собой этот архив
2. могут ли потребоватся данные из архива обратно и тогда что ?
3. зачем вообще париться с архивом ?

повторю вид иерархии:
Партия блоков
...блок1
...блокN
......Монитор
......Компьютер
..........Корпус
..........Материнская плата
...............память
...............кулер

ShtockДобрый день,г-г traktor123.Давно не общались. Может быть обойдемся без явной иерархии в заказе, а сделаем ее на уровне справочника услуг:
есть Ваш заказ с параметрами заказа, есть база изделий/услуг/прочее (причем все они имеют как и Ваши субъекты единый реестр с ID и указанием типа), там и храним рекурсивную связь на набор услуг, входящих в нее.Не забудьте,ведь есть стандартные услуги, изначально состоящие из ряда других и при их добавлении вашему клиенту желательно, чтобы автоматом добавилась вся куча услуг, а не каждая по отдельности. Я это называю "программа, управляемая данными".А для заказа просто храним таблицу с кодом заказа и кодом услуги. Так катит?

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

Но заказы сами по себе иерархическое понятие...
как я в номенклатуре укажу Компутер ???, что есть компутер ? - это некий набор никак не связанных деталей...
а если заказ = 10 компутеров + 1 винт, то у нас получается:
Заказ
...Компутер1
...Компутер10
......Монитор
......Сист. Блок
.........Винт
.........Память
...Винт
Т.е. юзер сказал хочу винт + 9 компутеров... для каждого компутера свой комплект независимых предметов, но принадлежащих именно к этому компутеру...

ShtockЯсно
А у меня к вам вопрос... :-)

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

TurboMutant


Выбор
1) 1 таблица "Заказ" и 1 иерархическая таблица "содержание заказа" c ParentID
2) просто одна иерархическая таблица Заказы c темже ParentID
Зачем делать 2 таблицы, если можно сделать одну ?

Shtock1. В моем бизнесе клиент и контрагент разные вещи, поэтому есть такое отношение и, соответственно, разные атрибуты.
2. Роль у нас - это вид деятельности.Поэтому аптека и банк прекрасно ложатся в эту модель. Ну и делаете список ролей. Не очень понял вопрос -:)

вот я сделал так:
1. Persons - общие поля + PersonType
2. Relations
3. Roles(Relations) - т.е. связь 1:1 роли и Отношения.

Работа в базе идёт от субьектов с типом PersonTypeID = "Наша фирма"

например субьект с ID = 10 - может быть клиентом у нашей фирмы с ID = 1
но он не есть клиент для нашей фирмы с ID = 2
т.е. он контрагент только для нашей фирмы с ID = 1 и мы создаём только одно отношение с типом является клиентом в таблице relations(и соответственно строчку с ролью клиент).
Если же он является и клиентом для ID = 2, то в relations - 2 строчки является клиентом для субьекта ID = 10.

т.е. роли - понятие относительное....

Но есть также не роли контрагентов, а роли Субьектов, которые не зависят от других субьектов.
Например если юр лицо - это банк, то всё это его св-ва. их не отберёш у него, если он также и сеть, то эти св-ва тоже от него не отберёш...
но как узнать если я выберу клиента, какие св-ва ему принадлежат ?
какие ролевые отношения - понятно - смотрю на relations...

traktor123но как узнать если я выберу клиента, какие св-ва ему какие
точнее выберу не клиента а субьекта...

TurboMutant traktor123
Выбор
1) 1 таблица "Заказ" и 1 иерархическая таблица "содержание заказа" c ParentID
2) просто одна иерархическая таблица Заказы c темже ParentID
Зачем делать 2 таблицы, если можно сделать одну ?

А зачем разные по сути вещи объединять в одну таблицу? А вдруг у "заголовков" заказов появится большое количество дополнительных атрибутов. Например, "исполнитель заказа" или еще что либо. Все это придется повторять на каждой строке "мегазаказа". Для ответов на вопросы "а сколько заказов..." придется лазить по огромной таблице, делать групповые операции...
В чем преимущество вар.2, в каких условиях они проявляются, нельзя ли пояснить?

на самом деле, в базовом варианте, заголовок заказа имеет только одно единственное лишнее поле - ссылка на контрагента.
всё остальное базовое - общее.

если появятся дофига новых аттрибутов у шапки, я их просто вынесу в доп таблицу связанную по id 1:1...
тоже самое касается и разных единичных заказов - появляется чтото новое - создаю новую таблицу 1:1...

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

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

не вьехал

Shtock
прямо в таблице типов ролей/отношений делайте поле с наименованием таблицы, где лежат данные свойства. Другого пути imho нет.

вы имеете ввиду для каждой таблицы с доп св-вами своё поле в суперклассе предке ?

Shtock
P.S. А Вам точно нужна универсальность, которая уже есть в покупных системах?Не боитесь ли на ее реализации потерять много времени?
[/quot]

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