Цитата:
Сообщение от
George Nordic
SIFT или что-то подобное. Т.е. вполне возможно, что пишут служебную инфу типа остатки на дату (в разрезе аналитик? а как иначе?). Таким образом, можно существенно поднять и скорость вычислений. Да, зато при коррекции итоги надо пересчитывать...
С Уважением,
Георгий
Поискал информацию по SIFT. Думаю, ничего подобного SIFT там быть не должно. Тут разработчики явно декларируют отсутствие каких либо изменений в "регистрах" в момент проведения складских операций. Явно указывается, что используются только операция вставки строк в "таблицу складских остатков" - ImTrans. Остаток при этом - это всегда сумма по подмножеству строк в ImTrans.
Разработчики утверждают что в результате этого:
- Полностью решена проблема с блокировками при проведении складских операций.
- Появляется возможность проводить процедуру сводного планирования не прерывая обычные операции.
- Скорость выполнения запросов и отчетов по складу, а также проведения складских операций существенно повышается.
Я исхожу из того, что эти их утверждения обоснованы - на мой взгляд косвенно это подтверждается хотя бы тем, что они не боятся добавлять в (традиционно довольно тяжелую) форму "В наличии" весь тот функционал, который они добавляют - суммовые остатки, выверку с главной книгой, все новые возможности по группировке, остатки на произвольную дату и т.д.
То есть мне кажется , что архитектурно подход FSB Development скорее противоположен подходу, реализованному Navision, что с этой точки зрения есть какая-то такая градация (для примера беру заказ с одной строкой):
- Navision - В момент разноски заказа обновляются значения множества SIFT ключей.
- Стандартная Аксапта - в момент разноски заказа обновляется значение соответствующей строки в InventSum
- Inventory II - В момент разноски заказа вставляется пара строк в ImTrans.
Сейчас ключевым мне кажется вопрос - как удается быстро получать информацию по остаткам на текущую дату без использования таких агрегатов как SIFT или хотя бы InventSum. Возможно, что этот алгоритм легко расширить и для получения остатков на произвольную дату.
Сначала мне казалось, что бэкграунд процесс просто помечает все "неактивные" записи ImTrans. Но во первых не очень понятно, как их надежно определить, во вторых тут появляется UPDATE на ImTrans, который вроде бы не очень согласуется с предыдущими декларациями, в третьих есть опасение, что "активных" записей при этом окажется все же слишком много, чтобы можно было получить заявленный существенный прирост производительности, ну и наконец - совсем непонятно, их каких соображений такой традиционный алгоритм "закрытия" записей по складским остаткам можно назвать "революционной watermark технологией"
Какие то догадки у меня зреют, постараюсь позже сформулировать.
Интересно, а какая в этом плане архитектура у таких ERP как SAP и ORACLE?