Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft Access Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
 Основы проектирования складской БД (v. 2)  [new]
Geo
Member

Откуда:
Сообщений: 6887
В этом топике я опишу несколько вариантов структуры складской БД, от самого простого до довольно "продвинутых" видов, и постараюсь в нескольких словах указать их плюсы и минусы. Возможно, со временем кто-то возьмется окультурить изложенную ниже информацию и довести ее до вида, пригодного к опубликованию в 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 для решения этой проблемы вводится механизм "последовательности документов", который предназначен, в сущности, для того, чтобы в нужный момент сказать пользователю: "раз вы не потратили время на перепроведение, то мы умываем руки и не обещаем правильных оборотов". Другим вариантом решения этой проблемы может послужить полный запрет редактирования документов "закрытого периода". Чтобы отредактировать документ из закрытого периода, надо будет вводить либо механизм открытия периода, либо практику сторнирующих документов.
- программа уже становится не наколенной поделкой, а довольно непростым в написании продуктом.

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

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

Сообщение было отредактировано: 22 янв 13, 18:26
20 янв 13, 15:48    [13798524]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
qwerty112
Guest
Geo,

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

К сообщению приложен файл. Размер - 29Kb
20 янв 13, 16:05    [13798570]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
Geo
Member

Откуда:
Сообщений: 6887
qwerty112
Geo,

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

Картинка с другого сайта.

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

Сообщение было отредактировано: 20 янв 13, 16:09
20 янв 13, 16:06    [13798574]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
Geo
Member

Откуда:
Сообщений: 6887


К сообщению приложен файл. Размер - 17Kb
20 янв 13, 16:06    [13798575]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
Geo
Member

Откуда:
Сообщений: 6887


К сообщению приложен файл. Размер - 33Kb
20 янв 13, 16:07    [13798577]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
Geo
Member

Откуда:
Сообщений: 6887


К сообщению приложен файл. Размер - 9Kb
20 янв 13, 17:14    [13798747]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
Geo
Member

Откуда:
Сообщений: 6887


К сообщению приложен файл. Размер - 29Kb
20 янв 13, 17:16    [13798752]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
Nebo
Member

Откуда:
Сообщений: 2862
Geo,

Сразу же хочется Вас попросить привести алгоритм контроля отрицательных остатков товара
в Ваших структурах. Сможете?
21 янв 13, 01:27    [13800164]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
Nebo
Member

Откуда:
Сообщений: 2862
Geo,

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

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


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

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

Потому-что в Аксессе нет транзакции на чтение.
Пока я читаю данные из таблицы остатков,
кто-то теоретически их может изменить в этой таблице, в момент чтения.
21 янв 13, 01:36    [13800177]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
сосед акцессник
Guest
2Geo

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


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

Вот я ничего не знаю про складской учет. (Действительно не знаю не знаю - не занимался этим).
По прочтении топика - какую главную умность, как человек не занимавшийся никогда складским учетом, я должен усвоить?
21 янв 13, 02:26    [13800239]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
сосед акцессник
Guest
пардон за дефекты речи в виде заиканий.
21 янв 13, 02:28    [13800240]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
t1002
Member [заблокирован]

Откуда: Castigat ridento mores
Сообщений: 505
Складской учёт, а товаров нет. Как это понимать? Учёт документов?
21 янв 13, 04:15    [13800287]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
qwerty112
Guest
t1002
Складской учёт, а товаров нет. Как это понимать? Учёт документов?

таб. dNomenkl
21 янв 13, 04:17    [13800288]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
t1002
Member [заблокирован]

Откуда: Castigat ridento mores
Сообщений: 505
qwerty112,

Разве в номенклатуре не может быть несколько товаров? А следовательно учёта товаров тут нет, есть учёт документов.
21 янв 13, 04:26    [13800292]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
qwerty112
Guest
Geo
Вариант 1.
....
Вариант 2.
...

исключительно, "для полноты коллекции", можно ещё упомянуть "промежуточный" между в.1 и в.2 вариант организации структуры "Документ",
когда есть одна табл.Docs с общими для всех видов документов реквизитами, и с ней связанны 1:(1,0) 3-и таб.с "уникальными" для этого документа реквизитами,
хотя и советовать делать так (по этому, промежуточному варианту) в Акцессе, имхо, стоит в самую посл.очередь

---
...и так, если из "вредности" только, ещё :
поле Summ, в DocTable - и в вариантах без "Регистра" (Operations) - "не одобряю" :) ,
а в вариантах с "Регистром" - точно лишнее ...

имхо, конечно
21 янв 13, 04:27    [13800294]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
qwerty112
Guest
t1002
qwerty112,

Разве в номенклатуре не может быть несколько товаров? А следовательно учёта товаров тут нет, есть учёт документов.

да нее, это ты не про ту номенклатуру говоришь,
в смысле - есть понятие "Номенклатура изделия" - то из чего это изделие состоит,

а тут другая "Номенклатура" - ассортимент, что ли :)
вообщем, 1С-ники, например, "сплош и рядом", называют то, что "честный акцессник" назовёт "СправочникТоваров" - справочник "Номенклатура"
21 янв 13, 04:38    [13800298]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
t1002
Member [заблокирован]

Откуда: Castigat ridento mores
Сообщений: 505
qwerty112,

Так я не 1с-ник, поэтому не понимаю, как справочник товаров превратился в номенклатуру. Вообще действительно всё смахивает на логику 1с.
21 янв 13, 04:42    [13800299]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
qwerty112
Guest
сосед акцессник,

моё имхо, если не возражаете :)

сосед акцессник
О чем этот топик, для кого

поиск по "склад" даёт 9-ть страниц тем
сосед акцессник
и зачем?

как "стартовый пинок" в нужном направлении
сосед акцессник
Чтобы начать с чего-нибудь простого - есть хоть какие-нибудь осмысленно озвучиваемые соображения, по которым в складской базе "документы" оказались центральным логическим понятием?

схема описывает "движение по складам"
инициируется и фиксируется это "движение" - документами, ... вроде бы всё логично ...
сосед акцессник
Если "документов" достаточно - логика какого сорта заставляет довешивать к ним "операции"?
Там что-то с докаументами не так или это "денормализация"?

денормализация (это "регистр" 1С-вский)

простота и скорость формирования запросов(не в смысле query, а в смысле вопрос-ответ) на остатки
Остатки (Rests) - из тех же соображений (1С-вские "Промеж.итоги" или как_там_их ...)
сосед акцессник
По прочтении топика - какую главную умность, как человек не занимавшийся никогда складским учетом, я должен усвоить?

когда понадобится занятся складским учетом,
и нужно будет делать схему данных этого "занятия",
нужно НЕ изобретать "велик" (не поедет :) ), а пройти в этот топик и выбрать на "свой вкус", и "допиливать" уже её под конкретные требования, конкретного/своего БП
21 янв 13, 04:44    [13800301]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
qwerty112
Guest
t1002
qwerty112,

Так я не 1с-ник, поэтому не понимаю, как справочник товаров превратился в номенклатуру. Вообще действительно всё смахивает на логику 1с.

это - да, это - есть

только, вот могу сказать, что сколько не видел вариантов этого "Склада",
все "рабочие" - с такой логикой (с такой же сутью - документы, регистры, ... - пусть как угодно по другому названными, но с таким смыслом)
с другой - тоже есть, но почему-то "включаеш - не работает" :)
21 янв 13, 04:52    [13800303]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
t1002
Member [заблокирован]

Откуда: Castigat ridento mores
Сообщений: 505
qwerty112
с другой - тоже есть, но почему-то "включаеш - не работает" :)


У меня работает. Не знаю насколько она другая, но я там отталкиваюсь от товара и его прихода на склад. Правда склад - только часть техпроцесса.
21 янв 13, 05:16    [13800320]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
qwerty112
Guest
t1002
qwerty112
с другой - тоже есть, но почему-то "включаеш - не работает" :)


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

нуу, давай - показуй схему, посмотрим :)
21 янв 13, 05:19    [13800323]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
t1002
Member [заблокирован]

Откуда: Castigat ridento mores
Сообщений: 505
qwerty112,

Это я делать не буду, не даст она ничего, отдельно склад оттуда я не вырежу, он встроен в техпроцесс, да и имена полей описывать тоже долго и хлопотно. Плюс свои нюансы, но никаких документов там нет.
21 янв 13, 06:47    [13800343]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
Nebo
Member

Откуда:
Сообщений: 2862
+1

Respect автору топика за тему:)
21 янв 13, 09:56    [13800720]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
SangYong
Member [скрыт]

Откуда:
Сообщений: 671
на каждый локейшн своя таб-ца ?
как-то меня сомнения разбирают....

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

почему не держать актуальные остатки
в виде отдельного справочника... ? скрость
и удобство визуализации увеличивается в разы

сложновато как-то засхемить всю дурь
в которой приходится ползать.
21 янв 13, 10:11    [13800823]     Ответить | Цитировать Сообщить модератору
 Re: Основы проектирования складской БД  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Вариант 1 - не нахожу причины для подобной структуры бд. Метаданные отлично хранятся в отдельной таблице.

Остальные варианты надо рассматривать не с точки зрения эстетической красоты, а с точки зрения запросов пользователя, как правильно описал Geo, каждый вариант характеризуется длительностью(малой или большой) аналитики по динамике оборота, остатков и тд(допустим, изменения остатков за 3 года в динамической базе - достаточно печальный отчет, который вынудит программистов раз в период так или иначе агрегировать данные за период)
21 янв 13, 10:49    [13801126]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
Все форумы / Microsoft Access Ответить