CustInvoiceTrans кластерный индекс

[Tarrash]

А не может быть такой ситуации (пока теоретически).

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

В это время другая обработка вставляет уже другие записи (RecId резервируется позднее).

После этого вставляются с записи из первой обработки.
Причем значения RecId будут меньше, чем из второй обработки.
В результате перестроение кластерного индекса.

Ведь резервирование RecId осуществляется средствами DAX-а а не SQL

[Tarrash]

Андре, дело в том что кластерные индексы оправданы в основном для редко изменяемых таблиц (это в основном справочники). И konopello абсолютно прав, если записи вставляются в СТРОГОМ порядке возрастания RecId то обновление кластерного индекса по RecId не приводит к большим затратам по производительности. Но вопрос, всегда ли записи будут вставляться СТРОГО по возрастанию RecId?

[Yprit]

Цитата:

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

дело в том что кластерные индексы оправданы в основном для редко изменяемых таблиц

Простите, а на чем основывается подобное заявление?

[Tarrash]

Yprit, примерно что-то подобное уже обсуждалось

Посмотрите, пожалуйста,

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

[Tarrash]

Yprit, вернее было бы сказать, индекс оправдан для, таблиц для которых значение ключа кластерного индекса монотонно возрастает/убывает или вставка записей в данную таблицу происходит достаточно редко. Прошу извинения, если не четко формулирую проблему. Но вопрос в другом: насколько ОПРАВДАН кластерный индекс ИМЕННО на таблице CustInvoiceTrans?