Нид хелп

← →
Ломброзо © (2007-01-18 00:08) [0]

Имеются следующие входные условия
1) Деревянный справочник номенклатуры ~10 тыс. записей
2) Цены реализации определяются только в национальной валюте
3) Для каждой позиции в номенклатурном справочнике может быть определено несколько типов

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

номенклатуру, а также произвольное количество дополнительных прейскурантов, включающих в

себя все некое подмножество позиций, содержащихся в основном прейскуранте
5) Цена реализации может меняться довольно часто (возможно, даже несколько раз в день)
6) Каждый договор всегда содержит ссылку на один из прейскурантов, причем для первой

категории договоров цены, определенные в прейскуранте на момент заключения договора, должны

быть фиксированы на весь срок действия договора, для второй категории договоров (навроде

оферты для магазинов) при совершении продажи всегда берётся цена, установленная на дату

продажи
7) Должна поддерживаться функция группового изменения цены для данной номенклатурной единицы

во всех прейскурантах с сохранением истории изменения.

В общем, полный, как тут кто-то намедни изящно выразился, arctic fox. Я изучил реализацию

прейскуранта в парусе и 1С. Там все как-то проще.

Структуру таблиц в черновом виде я накидал:
1) Прейскурант (код, наименование, тип={фиксированая цена, актуальная цена})
2) Версия прейскуранта (код версии, код прейскуранта, Дата изменения)
3) Цена (код цены, код версии прейскуранта, код номенклатуры, код типа цены реализации,

цена)
4) История изменения цены

Не могу принять концептуальное решение по проблеме хранения истории цены и прошу дельного совета :)

Вижу два варианта решения задачи:
1) Запретить изменение отдельных позиций номенклатуры в прейскуранте. То есть предполагаем, что все цены в каждом прейскуранте должны изменяться пользователем "пакетно", после чего система отправляет старую версию прейскуранта в архив, формируя как бы срез цен, и делает актуальной "новую" версию прейскуранта. Это решение чревато тем, что после пары тысяч нажатий кнопки "сохранить" база неимоверно распухнет
2) ОтказатьсЯ от хранения версии прейскуранта и рассчитывать срез цен на заданную дату динамически.

← →
Ломброзо © (2007-01-18 00:08) [1]

Извиняюсь за форматирование. Это Notepad

← →
Sergey Masloff (2007-01-18 00:13) [2]

Может чего не понимаю но все ж просто... Плоская тарифная таблица

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

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

← →
MikePetrichenko © (2007-01-18 00:19) [3]

> Извиняюсь за форматирование. Это Notepad

Странно, а я обычно браузером для промотра интернет страниц пользуюсь. В частности - у меня IE.

А теперь по теме: метод FIFO знаешь? Вот его аналог и применяй. Т. е. новая цена - новая запись (с датой).

← →
Ломброзо © (2007-01-18 00:21) [4]

Sergey Masloff (18.01.07 00:13) [2]
Ага. А без атрибута "окончание действия" можно обойтись? Юзаю Oracle - в нем вроде есть аналитические функции (LAG, LEAD), позволяющие манипулировать диапазонами. Или это сложнее?

← →
Sergey Masloff (2007-01-18 00:24) [5]

Ломброзо © (18.01.07 00:21) [4]
Нет не сложнее. Нормально.
А насчет постоянно действующих цен просто закрой выборку из таблицы функцией с флагом по какой версии брать. В простом случае она просто на день оказания услуги цену возвращает во втором - на дату заключения действующего договора.

> Sergey Masloff (18.01.07 00:13) [2]
упрощаешь, но не принципиально
> Таблица цен с десятками миллионов записей при нормальных индексах будет просто летать (проверено занусси
1/10 - electronically tested, как пишут на презервативах, правда, на простецкой технике
partioning option не помешает, это ея случай

Sergey Masloff
MikePetrichenko

Спасибо, утряслось.

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