Доброго времени, коллеги.
Подскажите возможные варианты..
Требуется организовать «склад». Учета материалов.
Вот примерный вариант:
"склад""накладная""ведомость" код склада код накладной код накладной материал дата материал количествокод складаколичествокод операции (приход; расход; перемещение и т.д.)кладовщик
склад – это по сути текущее остатки (состояние склада)

Далее «накладная» - это группировка для ведомости. Ну и зависимая от накладной «ведомость» - по сути, расшифровка содержимого накладной.

В общем то, выстроить логику не сложно – формируя ведомость обновлять склад..
Вопрос в другом:
Требуется отображать данные в виде:
Дата Склад материал на начало приход расход остаток на конец.

Вот тут я задумался.. Имея текущее состояние склада мы не имеем его историю, ответ на вопрос «что было со складом хх числа хх года» уже не так тривиален, потребуется перебирать таблицы движений (накладные + ведомости), не уверен что это есть хорошо в условиях большого количества записей.
Думал создать избыточную таблицу как просят Дата Склад материал на начало приход расход остаток на конец.
И писать её при движении материалов, но, такая таблица даст данные только на те даты, в которых было движение и то, по тем материалам по которым было движение.. Ну и вопрос «а когда её заполнять, если нет движения.. повесть задание на 12 ночи»?
Требуется:
датаскладматериал ост.на начало приход расход ост.на конец20/05/2010 0104-1 0005689 150 50 30 17021/05/2010 0104-1 0005689 170 0 0 17022/05/2010 0104-1 0005689 170 40 0 21023/05/2010 0104-1 0005689 210 0 50 160
Т.е. показать на любой период/число наличие материалов не смотря на их движение
Может кто вариант предложит?

я понимаю что есть отдельная ветка "проектирование БД", но тут вопрос не столько в организации БД, сколько в реализации на Orаcle.

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

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

Ramin, спасибо, полистаю.
просто сейчас вот подумал, а не добавить ли в "ведомость" поле "остаток на начало"..
При формировании ведомости, можно подтягивать остаток.
Это даст, имхо, много удобства..

Raminв чем сложность реализации? на дату проведение транзакции смотришь, если есть запись уже на эту дату обновляешь если нету обновляешь date_to на дата транзакции-1 и вставляешь новый с date_to = 31.12.3000
не очень понял со второй датой..

таблица склад, это просто для удобства..
основное в проводках (накладная + ведомость к ней).

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

Или, это в общем то нормально, и можно позволить это?
Просто, SELECT * FROM TBL - для рабочей бд мне кажется крайне жестоким и не допустимым, а тут, фактически перебор пойдет каждый раз от начала и до конца...

suPPLerФизическая модель всегда опирается на логическую. А у Вас пока и логической нет.

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

Это лучше обсуждать в Проектировании БД.
да понял что в "проектирование БД" бежать надо..
Смена 8 и 12 часов.. взависимости кто смотрит, кто-то смотрит по утрам и требует остатки на 8 утра (с 8 утра прежних суток). Как такового "закрытия" нет. Производство круглосуточное.
Расход, наряду с кладовщиком, списывается и в автоматическом режиме системой (САУ).

логика.. гм, а как вы думаете я добрел до чисто практических вопросов? Не было бы логики, эти вопросы и не возникли бы, модель была построена и учитывала всё, как оказалось почти всё..
И даже начала работать, пока не появились "глупые" вопросы, о которых раньше и не подозревали.
Этот вопрос только часть...

ну и.. Oracl налагает ограничения которые надо учитывать - я немогу в тригере сама себя смотреть и/или что-то делать..

Raminstells2ну и.. Oracl налагает ограничения которые надо учитывать - я немогу в тригере сама себя смотреть и/или что-то делать..
с таким опытом я думаю вам пора рано писать систему складского учета
спасибо за мнение..
"не могу" не значит "не умею"..

suPPLerАнализируйте бизнес-процесс. При окончании смены должны быть сдача-приём остатков, этот документ и можно отразить в таблицу истории остатков. Если на практике такого документа нет, это не означает, что он не был заложен в порядок дня. Скорее, это будет свидетельствовать о том, что на производстве бардак. При автоматизации бардака получится не порядок, а автоматизированный бардак. Так что придётся в тесном сотрудничестве с заказчиком наводить порядок, а потом уже отражать это в Вашей системе.
Ваши слова до бога уши..
Бардак нельзя автоматизировать, верно.
Есть кладовщик, работает "в день" но, материалы списываются круглосуточно, и прийти могут в любое время - в зависимости от участка приход/расход оформляет мастер/бригадир. Потом, днем, кладовщик "подбивает бабки".. А утром, с 7 до 8, уже куча желающих посмотреть как прошли сутки/смена (как говорил, у каждого своя - 8, 12 часов)...
Насчет бизнес-логики согласен, копья уже поломаны пачками..

В общем, пока у меня работает так: при проведении проводки, я завершаю транзакцию после корректировки склада и "состояния склада" (было пришло ушло осталось).
Это даёт удобство в работе и не нагружает систему и тормозит приложения.
Но, меня это не устраивает + добавились требования, переписываю по новому, отсюда и вопросы..

stells2Это даёт удобство в работе и не нагружает систему и тормозит приложения.

описАлся
Это даёт удобство в работе и не нагружает систему и НЕ тормозит приложения.