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

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

Вариант 1.

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

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

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

Вариант 2.

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

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

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

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



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

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

Вариант 4.
Операции (проводки) + текущие остатки.



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

Текущие остатки хранятся на "последний момент". Чтобы посчитать остатки на любую прошедшую дату, или получить отчеты по движению товаров, используются те же запросы, что и в варианте 3. Отсюда получаем:

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

Вариант 5.
Периодические остатки.



В таблицу остатков добавляем поле "дата остатков". Текущие остатки, если они нужны, хранятся на дату, в которой программа работать не будет, например, на 01.01.1901. А с определенной периодичностью (зависящей, в первую очередь, от объемов товарооборота) создаются промежуточные остатки на начало этого периода. Например, на первое число каждого месяца. С введением периодических остатков мы получаем:

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

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

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

qwerty112Geo,

картинок, почему-то, нет ...


гм. Сейчас поправлю... Джудж место экономит и картинки в удаленных постах не хранит. Придется выложить их ниже

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

Можно ли вообще не хранить остатки, а рассчитывать их на лету для товара в расходной накладной?
Как при этом сделать контроль отрицательных остатков в MS Access?
Всё писал в первом посте.

На мой взгляд невозможно вообще сделать контроль отриц. остатков товаров в MS Access.
Я пытался. У меня не получилось.

Потому-что в Аксессе нет транзакции на чтение. Пока я читаю данные из таблицы остатков, кто-то теоретически их может изменить в этой таблице, в момент чтения.
Товароучетные системы писали и до MS Access, вообще без каких бы то ни было транзакций. И с отрицательными остатками, уверен, боролись.

Сосед-акцессник
Можешь простыми простыми словами сказать - какие семь красных линий ты хочешь изобразить перпендикулярно?
О чем этот топик, для кого и зачем?
На этот вопрос уже ответил Qwerty123, спасибо ему большое :)

Чтобы начать с чего-нибудь простого - есть хоть какие-нибудь осмысленно озвучиваемые соображения, по которым в складской базе "документы" оказались центральным логическим понятием?
Если "документов" достаточно - логика какого сорта заставляет довешивать к ним "операции"?
Там что-то с докаументами не так или это "денормализация"?
Таблица документов расположена "в центре" по двум причинам. Во-первых, мне так было удобнее рисовать. Во-вторых, очень часто при первом создании складской бд, люди приходят к схемам, похожим на 1ю или 2ю. Почему добавлена таблица "операций", я указал в разделе "Вариант 3". Если вам нравится этот термин, то да - это классический образец денормализации.

Вот я ничего не знаю про складской учет. (Действительно не знаю не знаю - не занимался этим).
По прочтении топика - какую главную умность, как человек не занимавшийся никогда складским учетом, я должен усвоить?
Как человек, никогда не занимавшийся - никакую. Если когда-нибудь придется заниматься, то этот топик, возможно, задаст направление для размышлений, сподвигнет провести необходимые тесты производительности и т.д. Авось пригодится, стало быть.

t1002

Так я не 1с-ник, поэтому не понимаю, как справочник товаров превратился в номенклатуру. Вообще действительно всё смахивает на логику 1с.
Как обычно, отдельная благодарность Alvk за его неоценимый вклад в обсуждение вопросов форума. Видите ли, дорогая редакция. От изменения синонима в названии работа таблицы меняется не очень сильно. Я специально консультировался. А термин "Товары" мне кажется менее подходящим, чем "Номенклатура". Потому что "уборку мусора", "резку металла" и прочие работы и услуги, даже за уши не притянешь к "товарам".

P.S. Вариант 4, я, вероятно, на досуге разделю на 2 подварианта. Когда хранятся только "текущие остатки" - "Отдельный справочник", как пишет "SangYong", и когда в процессе работы создаются промежуточные остатки. Всё-таки отличий между ними довольно много.

упустил

2 qwerty123
[i]...и так, если из "вредности" только, ещё :
поле Summ, в DocTable - и в вариантах без "Регистра" (Operations) - "не одобряю" :) ,
а в вариантах с "Регистром" - точно лишнее ... [/i]
В документах Сумма необходима категорически. Тоже пресловутая денормализация, но потенциальной головной боли с различными контрагентами и инстанциями из-за объяснений "почему расходится на копейку" гораздо больше. Я у себя рассчитываю сумму, если вводилась цена, и рассчитываю цену, если вводилась сумма. А храню обязательно всё. Никакие округления не должны менять однажды введенный первичный документ.

В "регистрах" же наоборот - нужна сумма, но бессмысленна цена. Цену оттуда считать не придется никогда, эти таблицы нужны только для формирования остатков/оборотов, а суммовые остатки нужны часто.

boobyв разделе "вариант3" есть слова про "проводки", в картинке - "операции". как понять - это про одно и тоже или нет?Да, это одно и то же. Поправлю.
boobyХотел услышать примерно вот о чем - если проводки "надо" - почему схемы без проводок-операций признаются за допустимые в том смысле, что технически правильные. Если без "проводок" можно, значит их наличие - размножение сущностей.
Если, наоборот, их "надо", то факт их существования сам по себе представляет какю-то существенную часть моделируемых бизнес-процессов."Надо их", или не надо - решать исключительно автору программы. Причины и следствия введения таблицы операций-проводок я указал.

boobyЛадно. извини за вторжение.
Не буду я читать этот топик.
Даже когда мне станет "надо".

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

booby"текущие остатки" - нечто, завязанное на понятие "сейчас".
Для кладовщика на конкретном складе - "сейчас" - вменяемо определяемое понятие - гляди на часы и оглядывайся по сторонам на
Для "продавцов", "плановиков", "бухгалтеров" ничего близко похожего на поняте "сейчас" нет. Все что угодно - вроде учетного периода, дня, квартала - есть, а "сейчас" - нет.Я не против.

booby<...> развития модели задачи <...> Пойнт здесь такой <...> содержательную часть модели, обремененную алгоритмической поддержкой заявленного бизнес-требования. <...> специальный ресурс под который <...> нет вменяемых бизнес-требованийи т.д., и т.п. Уважаемый Booby. Есть ли у вас силы и время превратить описанные мною, цитирую: "несколько вариантов структуры складской БД" в законченную и вменяемую (читай, понятную и годную для публикации в FAQ) статью, необремененную россыпью красивых и длинных слов, или со словами, вынесенными в четкие и понятные определения? Если да, я с удовольствием помогу в оформлении и редактировании. Если нет, освободите меня, пожалуйста, от гипотетических споров ради споров.

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

Как-то так, ага. )

ЗЫ.

авторP.S. Вариант 4, я, вероятно, на досуге разделю на 2 подварианта. Когда хранятся только "текущие остатки" - "Отдельный справочник", как пишет "SangYong", и когда в процессе работы создаются промежуточные остатки. Всё-таки отличий между ними довольно много. Разнес уже, кстати. Вчера еще. И еще пару штрихов cделал, по мотивам увиденных замечаний

boobyЛадно, раз мне нельзя задавать вопросы
Ах вот оно что... Я просто за оборотами "ты рожаешь" и "твоя личная фантазия" не разглядел знаков вопроса.
Тогда, раз
boobyмоя гипотеза состоит в том, что понятие "таблица остатков", отличных от "сейчас" становится, с высокой вероятностью, излишеством, желательным к удалению с целью упрощения поддерживаюх процедур, то докладываю: описание этой гипотезы более-менее подходит под обновленный "вариант 4" стартового поста. И в нем же написано, для чего вводится следующий вариант. Собственно, протестировать, на каком количестве записей на железе выбранной могучести вариант 4 начнет тормозить, очень легко. Дальше "пальцы складываются" на калькуляторе, и решается, надо ли ускорять расчеты в конкретном выбранном случае в ущерб простоте реализации, или не надо. Я по мере сил пытался это донести.