Мне кажется, что я сейчас представляю каким образом могла бы быть реализована технология Watermark с заявленными характеристиками. Хочу описать это, чтобы выслушать ваше мнение - какие недостатки этой реализации мне не пришли в голову.
Для начала повторение некоторых моментов, описанных в исходной статье или обсужденных в этой ветке.
В основе технологии лежит отказ от принципа регистрации текущих значений остатков в таблице InventSum. Проведение складских операций не сопровождается операцией UPDATE над строкой какой-либо таблицы, в которой хранится текущее значение остатков.
Вместо связки InventSum/InventDim для контроля остатков используется единая таблица ImTrans. При этом API модуля логистики меняется лишь минимальным образом.
Текущие остатки (и остатки на произвольную дату) получаются путем суммирования по некоему набору строк в таблице ImTrans.
При этом
fact-sheet подчеркивается
Цитата:
Все запросы отбирают лишь очень малую часть данных вследствие того, что строки таблицы весьма эффективно разделены на релевантную и нерелевантную часть без использования сложных индексных ключей, что ведет к непревзойденной производительности.
Каждая складская операция сопровождается вставкой одной или нескольких (чаще всего двух) строк в таблицу ImTrans.
Непосредственным источником при вставке строк в ImTrans чаще всего являются изменения в таблице InventTrans (вероятно реализовано через тригеры в БД).
Изменение строки в InventTrans сопровождается вставкой двух строк в ImTrans. Первая строка сторнирует предыдущее состояние InventTrans, вторая соостветствует состоянию InventTrans после изменения.
При удалении и при вставке строки в InventTrans в ImTrans вставляется по одной строке, со сторно состояния удаляемой из InventTrans строки, или с новыми значениями, соответственно.
Строки каждой такой транзакции объединены кодом - watermark. Вероятно вотермарки это значения типа int64, хронологически увеличивающиеся в порядке фиксации транзакций.
Для того, чтобы в работающей системе сохранить "снэпшот" состояния остатков на какой-то текущий момент, достаточно сохранить значение наибольшего вотермарка на этот момент. То есть текущие остатки это сумма по всем "релевантным" строкам
таблицы ImTrans, а остатки на момент сохранения "снэпшота" это сумма по "релевантным" строкам значения "вотермарков" которых меньше или равны этому "вотермарку". Такой "снэпшот" состояния остатков используется для расчета сводного плана в условиях круглосуточной работы системы.
(по данным
видеодемонстрации)
Строки в ImTrans могут создаваться не только на основе изменений строк в InventTrans. Для реализации расчета себестоимости по "средней за период" в конце каждого периода в ImTrans добавляются строки типа "Закрывающих период" и "Открывающих период". При этом "Закрывающие период" строки списывают остаток в разрезе складских аналитик,
а "Открывающие период" возвращают его обратно.
(по данным
видеодемонстрации)
Исходя их этих исходных данных для обеспечения эффективного расчета остатков (текущих и на произвольную дату) мне представляется примерно такая процедура.
В начале нового дня резервируется несколько служебных значений вотермарков. Например это может быть прописано в процедуре выдачи значения нового вотермарка - если дата изменилась, записать несколько служебных ватермарков на для этой даты.
Дальше в какой-то момент вступает в действие служебный процесс Inventory II. В отдельную служебную таблицу, со структурой аналогичной ImTrans сохраняются остатки по состоянию на полночь.
После этого единой тразнакцией в ImTrans вставляются все эти строки. У этих строк отдельный тип (вроде OnHand), единый вотермарк, из служебного диапазона, зарезервированного на предыдущем этапе. В этой же транзакции значение этого вотермарка записывается в качестве текущего параметра системы.
Возможен вариант, когда в транзакции вставляется два набора строк, первый с меньшим вотермарком списывает остатки, второй, с большим вотермарком - приходует их.
С этого момента текущие остатки это сумма всех строк ImTrans вотермарки которых больше или равны вотермарку приходования остатков.
Остатки на произвольную дату в прошлом: Существует таблица, в которой записаны вотермарки операций регистрации остатков на каждую дату.
Остаток на произвольную дату в прошлом - это объединение строк по этому вотермарку (вотермарк регистрации остатка на дату) и строк у которых вотермарки больше этого, а дата операции (физическая или финансовая дата проводки) меньше или равна искомой.
Вторая часть объединения отражает операции зарегистрированные задним числом. Возможно для эффективности такие строки ImTrans (по операциям, проведенным задним числом) сразу помечаются определенным признаком.
Коррекции по пересчетам, накладным расходам, и т.д. попадают в ImTrans штатным образом, в результате срабатывания триггера при изменении поля Adjustment в InventTrans, и попадают в текущем периоде. Так что они на остатки в прошлом не влияют.
Вроде бы все. Хотелось бы услышать ваше мнение - каковы слабые стороны такой реализации?
Используется ли подобный подход в каких либо других системах?