Кластерный индекс на InventTrans в AX 4.0

[Logger]

Цитата:

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

Я как пурист со стажем меняю обычно на кластерный индекс по RecId, но в целом готов согласиться с AndyD - отложенная запись в паре с кэшем контроллера разницу сглаживают достаточно сильно

Vadik, а тот факт что recid в общем случае не возрастающий счетчик - не мешает ? Опять же, до 2012-й еще и dataareaid болтался в индексе. Ну и при расщеплении проводки также новый recid будет. В чем же выигрыш ? За счет меньшего размера ключа ?

[Vadik]

Цитата:

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

тот факт что recid в общем случае не возрастающий счетчик - не мешает ?

Речь про несколько инстансов AOS ? Не мешает. При интенсивной вставке образуется непрерывная "горячая область", ее размер можете посчитать самостоятельно из своего количества AOS-ов, размера пула RecId (250), размера записи в InventTrans (около 900 байт) и условного fillfactor-а (50 - 100%). Получается несколько мегабайт на компанию, гарантированно "горячих" (уже находящихся в памяти) которые будут скинуты на диск одной или несколькими последовательными операциями записи (continuous writes), в отличие от множества мелких random writes по всему массиву при обновлении InventDimId. Ну то есть - никак не дороже. Скорее наоборот - у меня сейчас на рабочем инстансе согласно sys.dm_db_index_operational_stats расщеплений страниц на индексе по RecId на порядок (десятичный ) меньше чем расщеплений на TransOriginIdx. Плюс, расщепления по RecId при вставке - "виртуальные", так как по факту страницы как правило только в памяти живут и на диск еще не сброшены

Цитата:

В чем же выигрыш ? За счет меньшего размера ключа ?

• Меньший размер ключа некластерного индекса (а у нас их 9 в стандарте)
• Нет необходимости физически перемещать запись в InventTrans при обновлении InventDimId
• Нет необходимости обновлять записи всех некластерных индексов при обновлении InventDimId