Версия 1 (для архива)В этом топике я опишу несколько вариантов структуры складской БД, от самого простого до довольно "продвинутых" видов, и постараюсь в нескольких словах указать их плюсы и минусы. Возможно, со временем кто-то возьмется окультурить изложенную ниже информацию и довести ее до вида, пригодного к опубликованию в FAQ.

Несколько оговорок:
- русскоязычные названия полей, используемые в схемах, приведены исключительно для наглядности. Я рекомендую пользоваться во-первых, одним языком при описании структуры таблиц, во-вторых, языком английским. Рекомендую я это с точки зрения удобства написания программ. При использовании англоязычных названий вам придется реже переключать раскладку клавиатуры, и дело будет идти быстрее. Впрочем, никаких других причин не пользоваться русскими названиями, включая религиозные, я не знаю.
- справочники Складов, Контрагентов и прочие я описываю в линейном виде, хотя сам предпочитаю делать их иерархическими, по аналогии с приведенной структурой справочника Номенклатуры. Поскольку организация иерархии - это отдельная и объемная тема, то останавливаться на ней здесь я не буду.

Вариант 1.

Самый аскетичный вариант. Подразумевается, что все документы хранятся в общей таблице Doc, а их табличные части в одной для всех таблице DocTable. Для примера к таблице Doc "пристёгнуты" справочники Контрагентов и Складов, аналогично по мере необходимости добавляются и другие справочники, например: валют, причин списания, корреспондентских счетов и пр.

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

Плюсы:
- простая и компактная схема БД.
Минусы:
- много избыточной информации. Многие документы имеют исключительно свои поля, которые не используются в других документах. И чем дальше развивается программа, тем больше будет таких полей.
- при использовании выделенного sql сервера для обработки и хранения данных, придется писать громоздкие и неудобные в восприятии триггеры на таблицы Doc и DocTable.
- весьма неудобные запросы для получения остатков и оборотов.
- по мере роста базы очень большое время получения остатков и оборотов.

Вариант 2.

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

Плюсы:
- простая схема БД.
Минусы:
- неудобные запросы для получения остатков и оборотов.
- по мере роста базы очень большое время получения остатков и оборотов.

Примечание
Оба эти варианта очень просты, но отличаются сложностью обработки информации и получения отчетов. Поэтому имеет смысл делать одну или несколько служебных таблиц, которые заполняются по мере редактирования таблиц документов. При работе с полноценным sql-сервером их заполнение разумно делать триггерами, при использовании же "чистого" Access, они заполняются в процедурах обслуживания событий форм: при удалении, редактировании и создании записей. В последнем случае так же нельзя будет забывать обо всех других способах изменения таблиц, например, при импорте данных, загрузках из ТСД и прочее. Во всех этих случаях надо будет изменять и служебные таблицы.

Вариант 3.
Добавляем таблицу проводок. "Развивать" я буду вариант 2, но не вижу препятствий и для соответствующих изменений варианта 1.



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

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

Вариант 4.
Проводки+остатки.



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

Остатки можно хранить на "последний момент" и/или на определенные периоды, например, на 1-е число каждого месяца.

Плюсы:
- стабильное и небольшое время получения остатков и оборотов.
Минусы:
- запросы на получение оборотов должны будут считать входящие (а возможно и исходящие) остатки от даты ближайшего предыдущего периода рассчитанных остатков, что здорово их усложняет.
- изменение документов "задним числом" обязательно должно инициировать пересчет всех необходимых остатков. Что также требует довольно непростых обработок, и, кроме того, приводит к подчас очень приличному времени перерасчетов. Настолько приличному, что, например, в 1С 7.7 для решения этой проблемы вводится механизм "последовательности документов", который предназначен, в сущности, для того, чтобы в нужный момент сказать пользователю: "раз вы не потратили время на перепроведение, то мы умываем руки и не обещаем правильных оборотов".
- программа уже становится не наколенной поделкой, а довольно непростым в написании продуктом.

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

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