Вопрос проектирования базы данных - использование контрольных точек при расчете по кассе

Question

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

inventory item table  
id | location | item   
1    1          234
2    1          567 

receiving table
inv item | stamp      | quantity
1          2010-08-10   200
1          2010-08-30   10
2          2010-08-30   20

shipment table 
inv item | stamp      | quantity
1          2010-08-10   40
1          2010-08-30   5
2          2010-08-30   2

sale table 
inv item | stamp      | quantity
1          2010-08-10   10
1          2010-08-15   15
1          2010-08-30   1
1          2010-08-30   1
2          2010-08-30   2

checkpoint table
inv item | stamp      | quantity
1          2010-08-11   150
1          2010-08-28   135
2          2010-08-15   15

Расчет наличными для инв позиции 1 на 8/30 будет таким:

get most recent checkpoint(inv item 1, 8/30) returns 135 units on 8/28
on-hand = 135 + receivings - (shipments + sales) 
only rcv/shp/sales that occur between the most recent checkpoint 8/30

Расчет наличными для инв позиции 1 8/14 будет таким:

get most recent checkpoint(inv item 1, 8/14) returns 150 units on 8/11
on-hand = 150 + receivings - (shipments + sales) 
only rcv/shp/sales that occur between the most recent checkpoint and 8/14

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

Answer 1

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

1. Пункт «А» имеет в наличии количество 1.
2. Клиент заказывает 1 единицу «А». Количество в наличии теперь равно 0. (контрольная точка 1 минус 1 продажа)
3. Контрольная точка определена. Количество «А» теперь установлено на 0 единиц.
4. Товар "A" не может быть отправлен клиенту по какой-либо причине (способ оплаты клиента был отклонен, клиент отменяет заказ и т. Д.)
5. Элемент «A» теперь необходимо перевернуть, чтобы отобразить количество в наличии 1. Удаление записи «sale» ничего не изменит, поскольку оно было зарегистрировано до контрольной точки.

В этом случае есть пара решений, которые могут сработать (измените значение контрольной точки или, еще лучше, опубликуйте «возвращаемую» запись, чтобы был контрольный журнал), но это только один пример того, с чем вам следует подумать этот подход.

Answer 2

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

В случае, если вам нужно обновлять данные чаще, вы можете обновлять сводные таблицы несколько раз в день с помощью одного и того же пакетного задания. Однако, чтобы свести к минимуму недоступность данных, вы могли бы иметь 2 набора сводных таблиц: один набор, который вы загружаете вместе с запросами (загрузка которого занимает много времени, так как запросы выполняются долго), и «реальный» набор, который вы используете. отчитаться о. Но вы просто загружаете таблицы из первой сводной таблицы во вторую сводную таблицу после завершения запросов (очень быстрая операция, поскольку вы просто сбрасываете данные), поэтому время простоя минимально. Так что в целом процесс будет выглядеть так:

1. Загрузить таблицу summary1 с данными инвентаризации. Здесь вы выполняете запросы, чтобы выполнить «тяжелую работу».
2. Как только запросы завершатся, загрузите таблицу summary2 из summary1. Это будет единственное время простоя, которое испытывают ваши пользователи, поскольку даже во время загрузки summary1 они все равно будут сообщать о summary2, что не будет затронуто.