Остатки на дату.

[_AnK_]

120к проводок в InventTrans это именно что игрушечная база.

Видимо разработчики системы считают что наличие обычно будет считаться на дату гораздо ближе к настоящему времени, чем к "началу времен". Сложение проводок лет за 5 на производственном предприятии, когда нужно наличие на неделю назад это очень неправильно.

[Recoilme]

Цитата:

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

код я брал не из нашей рабочей базы... писал на память

1. на 16 миллионах этот запрос будет работать часа полтора так что в чем то мази прав, но только в чем то, потому что на стандартных классах это вообще не работает
2. Если сделать инвенттранс нормальным, построеным не по варчарам а поинтежеровским полям (вместо итемид - рекид и т.п.) - этот запрос будет работать на тех же 16 миллионах - 50 секунд

пункт 2 - это так, к слову хотя может пригодится построителям хранилищ для отчетности, буде таковые вообще есть в природе на этом форуме

[mazzy]

Цитата:

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

обрабатывает до полумиллиона проводок...

представь что Косяпта у тебя стала работать с 01.01.2004 отработала уже 2 года...
и отчет надо построить именно на 01.01.2004

вы чаще делаете отчет на неделю назад или на несколько лет назад?
насколько чаще?

[mazzy]

Цитата:

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

1. но только в чем то, потому что на стандартных классах это вообще не работает

Не понял.
Что "это"?

Цитата:

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

2. Если сделать инвенттранс нормальным, построеным не по варчарам а поинтежеровским полям (вместо итемид - рекид и т.п.) - этот запрос будет работать на тех же 16 миллионах - 50 секунд

Это революция.
Переход от естественных ключей к исскусственным.
Такое вряд ли будет в ближайших версиях.

[Владимир Максимов]

Цитата:

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

НЕТ! НЕТ! НЕТ!!! И еще раз НЕТ!!!
НИКОГДА так не делайте.

Этот код работат боль-мень приемлимо только на игрушечных данных малого объема!
Стоит вам только приблизиться к нормальному рабочему объему - ваша база умрет.

Здесь написано как Аксапта получает остатки на произвольную дату
http://axapta.mazzy.ru/lib/inventsumdate/

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

30 тысяч артикулов. Рассчитать остаток для каждого артикула на начало мая 2005 года по 2 фиксированным складам (InventLocationId). Это около 2 миллионов складских проводок

InventSumDatePhysicalDim:: onHandQty() - отработал примерно за 50 минут
Прямой запрос в Query Analyzer по схеме: InventSum - SUM(InventTrans) выполнился за 2 минуты (т.е. остаток на сегодня минус все складские проводки до интересующей даты)

Даже с учетом того, что при переносе запроса в синтаксис AXAPTA он слегка "притормозит", все равно ускорение получаю в разы

Конечно, это несколько не то, что предложил UNRW. Я иду не "с начала времен", а от текущей даты назад. Но, по большому счету, на вывод это не влияет.

Если речь идет о расчете остатка для нескольких артикулов, можно использовать классы семейства InventSumDate. Если же речь идет о массовом расчете остатков по большому количеству артикулов, то следует искать обходные пути. Классы для этого слишком медленные.

[mazzy]

Цитата:

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

120к проводок в InventTrans это именно что игрушечная база.

Видимо разработчики системы считают что наличие обычно будет считаться на дату гораздо ближе к настоящему времени, чем к "началу времен". Сложение проводок лет за 5 на производственном предприятии, когда нужно наличие на неделю назад это очень неправильно.

Полностью согласен.

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Вообще-то, даже чисто логически, вывод будет прямо противополжным. Одна групповая команда по всякому быстрее работает чем куча одиночных команд в цикле.

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

ОДНАКО: если вы говорите о групповой обработке, то расскажите как вы обработаете аналитике корректно в групповой обработке?

Еще раз: уважаемые, подумайте.

[UNRW]

в запросе групируется по InventTrans.InventDimId и группируем в InventDim по нужным аналитикам - это же элементарно и очевидно

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

кого не устраивает такой подход пусть используют стандарные отчеты

[mazzy]

Цитата:

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

в запросе групируется по InventTrans.InventDimId и группируем в InventDim по нужным аналитикам - это же элементарно и очевидно

Подумайте, пожалуйста.

[Wamr]

to mazzy
1 TableScan по InventTrans будет работать быстрей чем туча мелких запросиков по каждой номенклатуре и по неиндексированым датам (DatePhysical)
Конечно, эти 5 минут SQL сервер будет стоять в неудобной позе.. но недолго

[Recoilme]

Цитата:

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

Не понял.
Что "это"?


Это революция.
Переход от естественных ключей к исскусственным.
Такое вряд ли будет в ближайших версиях.

1. Ответил Владимир Максимов:
InventSumDatePhysicalDim:: onHandQty() - отработал примерно за 50 минут
Прямой запрос в Query Analyzer по схеме: InventSum - SUM(InventTrans) выполнился за 2 минуты (т.е. остаток на сегодня минус все складские проводки до интересующей даты)

значит для 16 миллионов - примерно 8 часов. А ещё нужен приход и расход = примерно 24 часа на построение оборотки = не работает

ЗЫ: я пробовал, через 1,5 часа снял задачу, у меня терпения не хватило

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

[Recoilme]

Цитата:

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

to mazzy
1 TableScan по InventTrans будет работать быстрей чем туча мелких запросиков по каждой номенклатуре и по неиндексированым датам (DatePhysical)
Конечно, эти 5 минут SQL сервер будет стоять в неудобной позе.. но недолго

О-о-о-о индексы в Аксапте это вообще отдельная тема.... То ли я совсем не понял теорию как надо строить индексы, то ли её совсем не понял тот кто их туда пихал Очень хотелось бы услышать чьё-ть профессиональное мнение по индексам хотя бы для того же инвенттранса...........................................................................................

[mazzy]

Цитата:

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

1. Ответил Владимир Максимов:

Все равно не понял.
Ну, да ладно. Надеюсь другие разобрались

Цитата:

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

2. Скорее наооборот Переходе от искусственных ключей Аксапты построенным по текстовым полям к естественным ключам для СУБД построенным по целочисленным полям.

Искусственные и естественные ключи - это термины.
Поищите. Найдете много интересного.
Поищите на этом форуме для начала. Тема обсуждалась неоднократно.

Цитата:

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

Об этом надо было думать Дамгардам при проектировании базы. Сейчас это можно использовать при построении хранилищ на основе аксапты

Они как раз думали.
Просто тогда СУБД были другими.
Тогда приортитеты были другими.
...Тогда - это уже 20 лет назад
http://axapta.mazzy.ru/lib/names/#chronicle

[mazzy]

Цитата:

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

То ли я совсем не понял теорию как надо строить индексы, то ли её совсем не понял тот кто их туда пихал

Хинты для понимания:
Хинт 1. их туда пихал не один человек. Их туда много кто пихал. На протяжении очень длительного времени. В разных странах. Для разных СУБД.
Хинт 2. аксапта позволяет включать/выключать функциональность. В частности: таблицы, ПОЛЯ, ИНДЕКСЫ. Какие именно таблицы, поля, индексы включены - зависит от закупленных лицензий.

Правильная настройка индексов в конкретных условиях конкретного внедрения - дело внедренцев. ИМХО.

[Vadik]

Цитата:

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

Правильная настройка индексов в конкретных условиях конкретного внедрения - дело внедренцев. ИМХО.

И все же хотелось бы пореже убирать косяки за вендором

[Recoilme]

Цитата:

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

Хинты для понимания:
Хинт 1. их туда пихал не один человек. Их туда много кто пихал. На протяжении очень длительного времени. В разных странах. Для разных СУБД.
Хинт 2. аксапта позволяет включать/выключать функциональность. В частности: таблицы, ПОЛЯ, ИНДЕКСЫ. Какие именно таблицы, поля, индексы включены - зависит от закупленных лицензий.

Правильная настройка индексов в конкретных условиях конкретного внедрения - дело внедренцев. ИМХО.

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

[mazzy]

Цитата:

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

И все же хотелось бы пореже убирать косяки за вендором

Это да... Особенно для самых распространненных комбинаций лицензий...

[mazzy]

Цитата:

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

Не планируется ли написание Вашей командой написание статьи на эту тему? Думаю это было бы чрезвычайно интересно большинству участников..

Если честно, то я не очень понял что именно вы хотите получить от такой статьи?
И чем эта будущая статья будет отличаться от того, что Vadik уже написал? http://axapta.mazzy.ru/lib/querytuning/

[macklakov]

Цитата:

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

приводящие к увеличению призводительности приложения в целом, а не конкретных запросов?

Наверное ты хотел спросить, какие конкретные запросы сильнее всего влияют на быстродействие типовых задач?

[Recoilme]

Цитата:

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

Наверное ты хотел спросить, какие конкретные запросы сильнее всего влияют на быстродействие типовых задач?

Может быть и так.. хотя не уверен, вряд ли это
"Какие надо добавить конкретные индексы для оптимизации конкретных запросов "

Пример: распространенная задача - считывание текущего остатка, какой индекс на инвентсам/инвентдим позволит максимально оптимизировать эти запросы для MS SQL? М.б. это должен быть кластерный индекс? Насколько затормозится вставка?
Т.е. для таких задач наверно надо делать комплексное исследование, не как оптимизировать конкретный запрос, а как это повлияет на процесс в целом ? Поэтому я и побаиваюсь туда лезть