dynamicsmatters: Performance and InventDim

[mazzy]

Так. Я кажется выразился невнятно.

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

Совсем как некоторые Майкрософты, партнеры или некоторые клиенты, которые переписывают Аксапту под девизом "мы сейчас за две недели не коленке сбацаем". Причем они уверены, что сбацают гораздо лучше, чем предшественники.

Теперь к обсуждению:

Цитата:

Сообщение от glibs

Если использовать WMS (даже без ГТД) — вполне реально. Партии и серийные номера раздувают InventDim сильно. В производстве это особенно актуально (там партии используются частенько, серийные номера иногда).

А селективность спасает только на определенных запросах. При раздутом другими аналитиками InventDim отбор проводок, которые относятся к определенному складу, например, превращается в трудоемкую задачу для сервера СУБД.

Именно. На "определенных запросах".

Автор должен был либо проанализировать что уже сделано и как можно улучшить с сохранением совместимости. Либо проанализировать свое предложение - не станет ли "спасительных опеределенных запросов" меньше.

Я не спорю.
В свое время писал Добавление аналитики (и другие темы)
и сейчас повторю: Аксапта работает с нормальной производительностью при условии что InventDim существенно меньше, чем InventTrans.

Большой InventDim - зло. Аксиома.

НО: во многих российских внедрениях проблемы возникают не из-за WMS, партий и серийных номеров. А из-за неправильно реализованного ГТД. Кроме того, народ добавляет складские аналитики, беря за образец ГТД, и делает это неправильно.

Одним только включением ГТД (и добавленных по его подобию аналитик) в список селективных полей можно решить проблемы производительности в 60-80% внедрений.
(Vadik правильно напомнил об индексе по ГТД. Это само собой разумеется)

Еще раз повторю: согласен, большой InventDim - зло.
Но разработчики стандартной аксапты об этом зле хоть как-то подумали, а автор "универсального" предложения - нет. Именно в этом заключается "ужас", на мой взгляд.

Цитата:

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

Смотри, Глеб. Давным давно мы говорили об ответственности за свои советы.
Я более, чем уверен, что и ты, и Vadik, и несколько других человек реализуют этот способ корректно.
И я более, чем уверен, что у большинства последователей этого совета будут проблемы с целостностью.

Будь внимателен и осторожен.
Предложенный тобой способ может быть и принесет выигрыш, но чреват массой засад и потерей целостности.
Поэтому я бы не рекомендовал так делать пока разработчик не будет уверен в своих действиях на 200%.

Цитата:

Сообщение от Vadik

Знаю, поэтому и говорю - "ужас"

Мы говорим о разных "ужасах"

Цитата:

Сообщение от Vadik

Мне кажется, это тупиковое направление.

Я с тобой согласен вот в чем: согласен, что тупиковым является направление "универсальных", "платформенных", "программистских" механизмов, которые, по мнению разработчика, будут работать "при любых настройках".

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

Но на мой взгляд, не менее тупиковой является и попытка сменить "шило на мыло", сменить одну универсальную таблицу на один универсальный массив.

Цитата:

Сообщение от Vadik

Да если бы оно от этого сильно менялось.. Индекс по номеру ГТД ведь в коде не протянули.

О-о-о... Это отдельная пестня.

Цитата:

Сообщение от Vadik

Так.. опять наезды на программистов

Да.
К сожалению

Цитата:

Сообщение от Vadik

Идея универсального механизма хорошая, но механизм пора чуток обновить с учетом того, что самих аналитик и их комбинаций чуть больше, чем задумывалось на этапе проектирования

Нет, Вадим.
Пора не "чуток обновить" механизм, а разделить его на несколько механизмов согласно логике и смыслу (возможно не универсальных)

Цитата:

Сообщение от Vadik

Да, тут человек недодумал скорее всего. Потому что получение остатков в разрезе аналитик теперь невозможно - либо запрос по транзакционным таблицам, либо перенос аналитик в InventSum

Насколько я понимаю, везде вместо InventDimID он предлагает вставить массив.
И в InventSum, и в заказах, и в журналах, и в накладных, и в транзакциях... Везде. А таблицу InventDim он предлагает удалить.

Цитата:

Сообщение от Vadik

Но не беда. Зато - идет мыслительный процесс

А вот тут ты скорее всего прав. Как всегда
Чел предложил и предоставил замечательный повод пообсуждать задачу.
Зря бурчу. Спасибо.

Цитата:

Сообщение от kashperuk

Слава богу, вроде как раз так и думает сделать. Что не может не радовать

Как именно? Разработчик сделает несовместимое решение?
Можно подробнее?

[kashperuk]

Цитата:

Сообщение от mazzy

Как именно? Разработчик сделает несовместимое решение?
Можно подробнее?

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