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

[Tarrash]

Всем доброго времени суток!

Кто нибудь, подскажет, зачем в DAX4 понадобилось создавать кластерный индекс по RecId? Не приведет ли это к снижению производительности при массовой обработки накладных в заказах?
Ведь в тройке индекс не был кластерным.
Заранее спасибо за пояснения.

[Tarrash]

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

[AvrDen]

Создание кластерных индексов на крупных таблицах, вряд ли оправдано

[konopello]

Цитата:

Кто нибудь, подскажет, зачем в DAX4 понадобилось создавать кластерный индекс по RecId?

ну если подумать что recId теперь состоит с 64-бит и выделяется инкрементно, то проводки физически будет расположены в порядке их создания.

[Tarrash]

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

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

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

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

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

[Tarrash]

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

[Yprit]

Цитата:

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

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

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

[Tarrash]

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

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

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

[Alexius]

Цитата:

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

ну если подумать что recId теперь состоит с 64-бит и выделяется инкрементно, то проводки физически будет расположены в порядке их создания.

Это если в базе только одна компания.

[egorych]

Цитата:

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

Это если в базе только одна компания.

В 4 врое как RecId выделяется на таблицу без учета компании. Или я что-то путаю ?

[Alexius]

Цитата:

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

В 4 врое как RecId выделяется на таблицу без учета компании. Или я что-то путаю ?

Ага, только никто не догадался, что из индексов по RecId (кластерных и некластерных) неплохо бы выкинуть поле DataAreaId, идущее первым или воткнуть его вторым.

[Андре]

Цитата:

Создание кластерных индексов на крупных таблицах, вряд ли оправдано

Каким образом кластерность индекса зависит от размера таблицы и почему ?

[Андре]

Цитата:

Не приведет ли это к снижению производительности при массовой обработки накладных в заказах?

Если для вас это важный вопрос - я бы поднял копию базы и погонял бы типичные сценарии работы с обоими вариантами индекса.

[Tarrash]

Спасибо за совет, Андре. Мы конечно погоняем тесты в разных варинатах, проанализируем планы выполнения запросов и т. п. и примем решение.

Но все равно интересно, почему именно для этой таблицы CustInvoiceTrans нужно было создавать кластерный индекс (прошу извинения за излишнюю дотошность). По InventTrans, например, нет кластерного индекса.

[Yprit]

Tarrash, если ответить прямо на Ваш вопрос - потому что по BP максимально возможное число (если не все) таблицы в БД должны иметь кластерный индекс. В 4-ке попытались приблизиться к этому стандарту, правда не всегда обдуманно и удачно. В случае с CustInvoiceTrans - наверное, это не лучший выход, но ничего старшного в этом я тоже не вижу.

[Андре]

Цитата:

по BP максимально возможное число (если не все) таблицы в БД должны иметь кластерный индекс

BP здесь не первоисточник. Например, таблицы без кластерных индексов не подвержены не экстентовой дефрагментации, ни внутренней. И в случае массовой вставки/обновления/удаления - неиспользуемое пространство будет лишь дырами в страницах. И проблема будет даже не в разрастании БД, а в том, что для того, чтобы выполнить скан такой таблицы необходимо прочитать на порядок больше страниц, нежели необходимо.

[Yprit]

Цитата:

Сообщение от Андре

BP здесь не первоисточник.

Ну, когда следование конкретному правилу BP в 90% случаях действительно является оправданным, то я обычно ссылаюсь на BP Можно обсудить, конечно, и преимущества куч перед кластреными индесами, и конкретные случаи выигрыша без использования кластерных индексов. Но это, скорее, для sql.ru уже. Поэтому я просто с Вами соглашусь Ну и ссылочку для комплекта

http://www.microsoft.com/technet/pro.../clusivsh.mspx

[Alexius]

Цитата:

Сообщение от Андре

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

А можно с этого места поподробнее ?
Насколько я представляю, таблица без кластерного индекса имеет внутренний уникальный 8-ми байтный ключ, последовательные значения которому присваивается при вставке записей и дефрагментация может возникнуть только при удалении записей, но не при вставке или обновлении.

PS. Это все для MS SQL, хотя для Oracle должно быть что-то аналогичное

[Андре]

Цитата:

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

На всякий случай - мое сообщение выше - как раз наоборот: преимущества кластерных индексов. Дабы не ввести никого в заблуждение.

[fed]

А единственный (и основной) минус кластерного индекса состоит в том, что во всех некластерных индексах, вместо RowId хранится ключ кластерного индекса. Поэтому при выборке по некластерному индексу, фактически делается две выборки: Сначала выбираются значения ключей кластерного индекса из обычного индекса, затем по значениям этих ключей, выбираются записи из кластерного индекса. Так что я вот к рекомендации BP отношусь достаточно настороженно; Кластерный индекс однозначно лучше только в том случае, если процентов 70 выборок делается ТОЛЬКО по нему, а все остальные индексы используются только в каких-то экстремальных случаях.