Производительность и ключ InventDim

[Logger]

Цитата:

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

Интенсивная вставка ? Обновления ? Мы все еще индекс на InventDim по InventDimId обсуждаем ? Напомню, основной способ доступа - singleton_lookup

Интересно, почему так получилось ? Неужели настолько часто дергается find(). Мне казалось что Invnetdim очень часто в джоинах бывает. Или они тоже могут приводить к такому способу доступа ?

[handy-comp]

Цитата:

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

Интенсивная вставка ? Обновления ? Мы все еще индекс на InventDim по InventDimId обсуждаем ? Напомню, основной способ доступа - singleton_lookup
AOS

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

Цитата:

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

А можно "на пальцах" показать как префиксы в номерной серии приводят к усиленной фрагментации при вставке ? А то мне как-то казалось что при выделении в рамках одной сессии значение номерной серии монотонно возрастает, а в случае множественных сессий и неиспользования предварительного выделения номеров из серии фрагментация даже меньше чем при индексе по RecId и множественных инстансах AOS

Вот тут хорошо описано про кластерные индексы http://www.somewheresomehow.ru/clust...key-selection/
На пальцах, записи физически отсортированы по кластерному индексу, если мы вставляем запись то с одним префиксом ключа то с другим (как здесь предлагалось для визуального разделения) системе приходится резервировать пустые места для вставки данных в разные места таблицы.

[Vadik]

Цитата:

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

Интересно, почему так получилось ? Неужели настолько часто дергается find()

Просто индекс по INVENTDIMID для любых других применений кроме лукапа практически бесполезен. Суррогат, часто используется для выборки отдельной записи, редко (практически никогда) - для range_scan-а (никто не запрашивает INVENTDIM c INVENTDIMID с XXX по XYZ). По сути любой range_scan по нему - это fullscan (SELECT * FROM INVENTDIM WHERE DATAAREAID = 'ABC'), которого всячески избегают.

Цитата:

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

Мне казалось что Invnetdim очень часто в джоинах бывает. Или они тоже могут приводить к такому способу доступа ?

Ну так INVENTDIM просто так (без WHERE) как правило не джойнится, а с WHERE как правило уже немного другие индексы используются

Цитата:

Сообщение от handy-comp

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

Это уже немного "вообще и ниочем", в дискуссиях ТАКОГО уровня абстракции я участвовать пока не готов.
Что касается INVENTDIM, повторюсь - нагрузка на вставку есть "о малое" от общей, а обновлений нет.
По поводу кластерного индекса по RECID "вообще" - повторюсь: это ОЧЕНЬ большое упрощение полагать что RECID в AX ведет себя подобно IDENTITY - достаточно за пять минут набросать на бумажке как идет вставка в системе с двадцатью компаниями и пятью AOS-ами (спойлер - никакого "монотонного возрастания значений там рядом не стояло)

[Logger]

Цитата:

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

По поводу кластерного индекса по RECID "вообще" - повторюсь: это ОЧЕНЬ большое упрощение полагать что RECID в AX ведет себя подобно IDENTITY - достаточно за пять минут набросать на бумажке как идет вставка в системе с двадцатью компаниями и пятью AOS-ами (спойлер - никакого "монотонного возрастания значений там рядом не стояло)

А вот в связи с этим интересно, зачем в 2012-й Аксапте до сих пор держатся за индексы по recId когда можно теснее интегрироваться с SQL Server и использовать разные специализированные примочки БД. Все равно, в отличие от предыдущих версий, база данных теперь одна, не нужно заморачиваться с совместимостью для разных БД.

[gl00mie]

Цитата:

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

интересно, зачем в 2012-й Аксапте до сих пор держатся за индексы по recId когда можно теснее интегрироваться с SQL Server и использовать разные специализированные примочки БД.

Потому что нельзя вот так взять и в рамках одной версии переделать все до основания А еще потому что из-за нормализации данных и фиговой тучи связей между таблицами по FK (RecId) стало очень непросто подчас корректно создавать/обновлять/удалять связанные записи. Раньше можно было из номерной серии выделить заранее все идентификаторы и неспешно их прописывать, куда надо, в произвольном порядке, а теперь нужно соблюдать последовательность, поскольку PK (RecId) выделяется только на вставке. Чтобы упростить работу, в частности, был сделан UnitOfWork:

Цитата:

The UnitOfWork class automatically propagates the primary key value to the corresponding foreign key field, when the row with the foreign key field is inserted. The call pattern for inserts is first to add one record at a time to your constructed UnitOfWork object. After all the inserts have been added, you call the saveChanges method to persist the inserts to the database. The pattern is similar for updates and deletes. You can add inserts, updates, and deletes in succession, in any sequence, and then call the saveChanges method.

Проделать такое в случае, когда вместо выделяемого AOS'ом RecId будут выделяемые СУБД identity, будет м... несколько труднее.

[handy-comp]

Цитата:

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

Это уже немного "вообще и ниочем", в дискуссиях ТАКОГО уровня абстракции я участвовать пока не готов.
Что касается INVENTDIM, повторюсь - нагрузка на вставку есть "о малое" от общей, а обновлений нет.
По поводу кластерного индекса по RECID "вообще" - повторюсь: это ОЧЕНЬ большое упрощение полагать что RECID в AX ведет себя подобно IDENTITY - достаточно за пять минут набросать на бумажке как идет вставка в системе с двадцатью компаниями и пятью AOS-ами (спойлер - никакого "монотонного возрастания значений там рядом не стояло)

Позвольте напомнить сам обсуждаемый вопрос:

Цитата:

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

..... Не лучше ли с точки зрения производительности, если бы InventDimId был бы типа int64?

Это не тоже самое что: давайте переделаем все связки через RecId.

[Logger]

Цитата:

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

Ну так INVENTDIM просто так (без WHERE) как правило не джойнится, а с WHERE как правило уже немного другие индексы используются

Это принципиально ничего не меняет. По Inventdim - это поле как бы не используется, но все равно значение используется в индексах по табличкам с которыми идет джоин (InventSum.InventdimID, InventTrans.InventDimId и.т.п) Ну и кроме того если по нему есть кластерный индекс в Inventdim - т.е. по факту поле все равно присутствует во всех остальных индексах и остаются в силе все соображения про экономию места для хранения значений ключа.

[Vadik]

Цитата:

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

Это принципиально ничего не меняет. По Inventdim - это поле как бы не используется, но все равно значение используется в индексах по табличкам с которыми идет джоин (InventSum.InventdimID, InventTrans.InventDimId и.т.п) Ну и кроме того если по нему есть кластерный индекс в Inventdim - т.е. по факту поле все равно присутствует во всех остальных индексах и остаются в силе все соображения про экономию места для хранения значений ключа.

Ну так я вроде очевидных фактов не отрицал
Осталось только продемонстрировать на сколько порядков увеличится производительность, и дело в шляпе

[Logger]

Ну я тогда не понял просто зачем вы упомянули про выбор индексов.

[AlexeyS]

Цитата:

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

Правда. Строка хранимая в юникоде как правило "длиннее" int64, это факт. А вот постулат о том что int64 "быстрее" (и насколько "быстрее") - неплохо было бы доказать

N лет назад оптимизировал кубы в базе, где номенклатура была набором цифр и кубы процессились доолго.
Когда кубы стали получать код номенклатуры в формате int (конвертация на уровне view), то процессинг ускорился раза в полтора-два