БД склада

← →
Sam Stone © (2006-10-12 19:34) [0]

Я, конечно, понимаю, что вопрос наверняка обмусоленный сотню-другю раз, но все же )
Набросок концептуалки - http://www.ljplus.ru/img/s/a/samstone/q1.GIF
Чтобы не было вопросов - "шаблон х.е." это заготовка для хранимого комплекта (например ящик водки :) в ящике 20 бутылок и тп :)). После копирования шаблона в хранимые единицы "комплект" можно будет разбазаривать ;) т.е., например, выдать 3 бутылки из ящика.
Вопрос такой: как лучше и удобнее для последующей работы прицепить учетную часть? Прием, перемещение, выдача груза. Я пока вижу 2 выхода: 1)таблица с хранящимся хламом разростается до ужасающих размеров, т.к. для статистики и отчетности хранятся все записи выданых грузов; 2)выданое перекидывать в другую таблицу, в приходе/выдаче перебивать ключи, ссылающиеся на груз либо заполнять доп. поле на таблицу "выдано (уехало со склада)". Как еще можно реализовать?

ЗЫ
забыл FK из шаблона и хранимых эл-тов на класс кинуть, но картинку лень перезаливать :)

← →
Zacho © (2006-10-12 19:58) [1]

Картинку не смотрел, лень :) но кое-что исходя из собственного опыта сказать могу.
В общем случае, самая удобная схема учёта - партионная. Т.е. есть таблица (может несколько таблиц, всё зависит от особенностей конкретной задачи) с документами на приход/расход/перемещения партий товара. То, что такая таблица разрастётся - не беда, конечно если СУБД не Paradox :) Впрочем, я видел вполне работающие подобные системы с гигабайтными базами именно на Парадоксе.
Для ускорения получения остатков на конкретную дату/конкретный склад/конкретный товар и т.п. можно сделать дополнительную таблицу с агрегатами, заполняемую автоматически.

> 2)выданое перекидывать в другую таблицу, в
> приходе/выдаче перебивать ключи, ссылающиеся на груз
> либо заполнять доп. поле на таблицу "выдано (уехало со
> склада)".

А в этом варианте геморроя будет не мерянно :)

← →
Sam Stone © (2006-10-12 20:31) [2]

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

← →
Zacho © (2006-10-12 20:47) [3]

Дык, в партионной схеме - "документная таблица" и есть та таблица, в которой "инфа о хранящемся хламе лежит". Агрегаты остатков - опционально, для ускорения работы.
Или ты о другом ?

Ну а насчёт распухания вообще.. Это действительно стандартно. При нормальной СУБД / правильном проектировании БД и приложений это никаких проблем не вызывает. Например, в складской БД с которой я последний раз имел дело была номенклатура около 70000, около 2000000 приходных/расходных документов и всё это шустро крутилось на P2-400 512 RAM, ~15 постоянных подключений, под IB 5.6
Если же "старые" данные действительно начинают доставлять проблемы с производительностью, то можно, например их перекидывать в специальные "архивные" таблицы или БД и т.п.

← →
Sam Stone © (2006-10-12 21:56) [4]

> Zacho © (12.10.06 20:47) [3]

> Дык, в партионной схеме - "документная таблица" и есть та
> таблица, в которой "инфа о хранящемся хламе лежит"

вроде об этом ) Накладная и хранящийся объект связаны многие-ко-многим или один-ко-многим, не знаю, как удобнее будет (объекты принятые по накладной ссылаются на нее или накладная ссылается на список объектов, которые по ней приняли).
Если есть возможность, пульни схему БД с которой я последний раз мне на мыло. samstone на мыле ру.

← →
Zacho © (2006-10-12 23:09) [5]

Sam Stone © (12.10.06 21:56) [4]
Если есть возможность,

Сейчас возможности нет. Если у тебя интерес к этому не пропадёт - попробую найти одну из ранних бет этой АСУТП (схемы БД коммерческих версий, извини, не имею права). Но это может занять пару дней. Просто у меня, похоже, оно или вообще не сохранилось, или где-то в завале болванок с архивами :) Если хочешь - пиши мне на мыло (в моей анкете), как найду - вышлю.
Впрочем, может быть тебе это и не потребуется - завтра с утра на форуме появятся гораздо более чем я компетентные в этом вопросе люди.
Дело в том, что в разработке этой хрени я участвовал 6 лет назад, а последний раз с ней работал 4 года назад. Естественно, многое уже забыл.

> Накладная и хранящийся объект связаны многие-ко-многим
> или один-ко-многим, не знаю, как удобнее будет
> (объекты принятые по накладной ссылаются на нее или
> накладная ссылается на список объектов, которые по ней
> приняли).

Кратко:
Есть справочник товаров (реально около десятка таблиц, от иерархического классификатора товаров до всяких разных атрибутов товаров), есть накладные (точнее, вообще довольно абстрактные "документы", и тоже не одна таблица). Документы ссылаются на участвующие в оперции товары. Данные типа количества, входной стоимости/наценки т.п. - в документах. Для быстрого получения остатков - есть таблицы с агрегатами, которые заполняются/модифицируются триггерами при проведении документов.
Расходные документы ссылаются на приходные ... и т.п.

В общем, спрашивай, что помню - расскажу.

← →
Sam Stone © (2006-10-13 00:30) [6]

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

Тогда подождем компетентных людей ) а если не появятся - напишу :)
А пока сам буду думать.

> В общем, спрашивай, что помню - расскажу.

собсна, чего убить/добавить в картинке в [0]? :) Это только набросок

← →
Sergey13 © (2006-10-13 08:37) [7]

> [1] Zacho © (12.10.06 19:58)
> Картинку не смотрел, лень :)

Аналогично. 8-)

> [0] Sam Stone © (12.10.06 19:34)
Ты как то странно начинаешь складской проект. Хранится у тебя "хлам", а главная проблема - "распухание" таблицы. А начинать надо с конкретного выяснения у заказчика - что за склад, как он работает, какая система учета, какую входную информацию он заносит сейчас и какая выходная информация его интересует в будущем, возможность комплектования/раскомплектования и т.д. и т.п.

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

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

Блин, не дописал... Основной упор делаю на размещение, перемещение и тп объектов (реализация логистики), поэтому мегаучет не нужен )

> [8] Sam Stone © (13.10.06 17:35)
> целью стоит написать не привязанную к чему-либо систему,
> а учет особо сложный и не нужен. Я хотел узнать, как лучше
> привязать документационную часть к системе хранения.

С такими познаниями в предментной области ты сначала "привязанную" напиши, ибо "не привязанная" - это следующий (более высокий) уровень сложности.
ЗЫ: Если конечно не воспринимать "не привязанная" как "на фиг никому не нужная". 8-)

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