Диапазоны учетн. таблиц хорошо или плохо на SQL

[dmites]

В учетных таблицах 32,5802,17 и т.д. использованиe диапазонов для отдельных филиалов вроде как оправдано и дает возможность работать без блокировок (именно этих таблицах) при учете да и необходимо при построении репликации без перписки учета.
Но с другой стороны - записи физически упорядоченны по Entry No. то есть там где заканчивается один диапазон тут же начинается другой (при FillFactor=100). Соответсвенно, для вставки записи в конец "верхнего" дипазона, то бишь в середину таблицы, надо "сдвинуть" записи в страничке, куда
вставляется запись. Т.к. страничка заполнена на 100 %, из неё выпихнется запись в следующую страницу и т.д. до конца..
Описание данного процесса находил в документации SQL, источник найти сейчас не могу, но вообщем категорически не рекомендуют выбирать кластерный ключ, приводящий к вставкам в середину таблицы ибо ужасным образом сказывается на производительности.
По идее, в таком случае хорошим будет кластерным ключ на целочисленном поле, заполняемым функцией DateTimeToInt т.е. новый записи в подавляющем своем кол-ве (учет задним числом не рассматриваем) будут попадать в конец таблицы.

Сказано - сделано. Но прироста ощутимого в производительности не ощутил.
Что не так ?

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

[dmites]

Нашел подтверждение "вредности" дипазонов
"...Относиться к выбору поля для кластерного индекса следует очень осторожно - например, если в эту таблицу часто производится вставка данных, а кластерный индекс наложен не на поле с автоприращением, то вполне может получиться так, что нам часто придется вставлять новые записи в середину таблицы. Результат - большое количество операций page split, фрагментация таблицы и, как следствие, серьезное падение производительности (за счет фрагментации и за счет того, что само по себе page split - достаточно ресурсоемкая операция...."