Метод findSum формирует запрос для получения суммарных остатков по заданной номенклатуре с фильтрацией по складским аналитикам.
Причем основной смысл метода - попытка оптимизации.
Предлагаю обсудить корректность данного кода и его подводные камни (с точки зрения производительности)
PHP код:
static InventSum findSum(
ItemId _itemId, // Код номенклатуры
InventDim _inventDimCriteria, // Список критериев отбора (фильтр по складским аналитикам)
InventDimParm _inventDimParm, // Флажки - какие из критериев использовать
InventSumFields _sumFields = InventSumFields::All // Сумма каких величин нас интересует
)
{
InventSum inventSum;
InventDim inventDim;
;
if (! _inventDimParm.isFlagSelective()) // (1) Не используются ли высокоселективные критерии (палета, партия, серийный номер)
{
// Запросы вида InventSum по индексу ClosedItemDimIdx - InventDim по индексу dimidIdx
...
}
else
if (_inventDimParm.inventSerialIdFlag && _inventDimCriteria.inventSerialId) // (2) Фильтруем по серийному номеру
{
// Запросы вида InventDim по индексу serialIdIdx - InventSum ItemDimIdx
...
}
else
{
// Запросы вида InventSum-InventDim без указания индекса
...
}
return inventSum;
}
(1) В общем случаи, я согласен с таким подходом (выборка всех остатков по номенклатуре будет меньше, чем выборка всех аналитик по складу). Однако, мне не понятно, почему здесь нет проверки на ГТД. И еще не разу не видел, чтобы кто-нибудь добавлял проверку по "своим" аналитикам.
(2) Тоже согласен с таким подходом. Только, чем так выделяется серийный номер, а не партия, палета или гтд?
Кроме того, если в системе есть "универсальный" номер, на который сваливается все непонятное, то система попадет в ступор.
P.S. Еще есть метод InventSum::newQuery, в котором формируется похожий запрос, но только через Query (точнее интересен queryAddHint). Там и (1) и (2) сделаны немного подругому, но с темеже проблемами.