Z1 писал(а) 26. Ноября 2008 :: 10:55:

Это я сам его удалил, чтобы не начинать холивар - Хендерсона многие воспринимают как догму.

Z1 писал(а) 26. Ноября 2008 :: 11:31:

Т.е. в RA "последовательный кластерный первичный ключ" - это супер, а в RG - нет? 

+ последовательный индекс колбасит гораздо меньше, чем какой нибудь GUID..

Z1 писал(а) 26. Ноября 2008 :: 11:21:


Ну типичная ситуация.
Провожу задним числом.
Нужен остаток товара "Бутылка".
Как будет производится расчет с таким индексом?

Z1 писал(а) 26. Ноября 2008 :: 12:52:


На 15 ноября 2008.
Остаток на 1 ноября будем считать известным - т.е. только данные из RA.
500 док. в день.
Фирма , склад - заданы.
Вопрос о допустимости проведения опустим - интересует только техническая сторона вопроса.

даже если говорить об отрицательных остатках то можно считать
что мы их проверяем в половине документов ( лукавлю конечно приход крупнее чем расход ) но перестроение кластерного индекса
будет происходить всегда ( таблицы  rg ). даже когда у Вас только
приход.
по поводу отрицат остатков также два соображения  УРБД может
вносить искажения это раз

Соображение номер 2 а не слишком ли дорого считать отрицательные остатки в модуле проведения в открытой транзакции - может это тоже вынести как отдельный  subj ?
Речь естественно идет когда у нас очень дикие нагрузки на базу.

И основной вопрос этого subj  зачем  именно Кластерный по rg

Статью прочитал мысль автора понятна и правильна.
Получается если мы перепроводим сейчас накладную за 03.02.2008
то возможны ситуации по таблице  rg :
1. это update и индекс не измениться
2. если это несколько insert то индекс влезет в туже страницу из-за
фрагментации
3. если индекс не влезет в нужную страницу вот только в этом случае будет пересчет индекса - но тогда уж пересчет так пересчет.
Вероятность невлезания возрастает вызвана еще и тем что insert идет
и в февраль,март,апрель,май,июнь,июль,август,сентябрь,октябрь,ноябрь

Ну тогда также не понятно чем кластерный индекс отличается от
некластерного уникального. Только тем что он первый и перестраивается в первую очередь и поэтому его вероятность выталкилкивания на другую страницу минимальна и при прочих равных условиях записи индекса "ближе" друг к другу
или есть еще какая либо "фишка"

berezdetsky писал(а) 26. Ноября 2008 :: 14:51:

Ты же сам вроде говорил в этой ветке  что индекс отдельно а данные тоже отдельно. см пост 8.

Тогда получается что  kiruha прав и индекс для rg сделан в 1с
хорошо и проблемы могут возникнуть только если мы залезаем в глубое прошлое и что-то там перепроводим.
Для ra тоже все ok c идексом так как ID документа не меняется
и все движения ra будут на одной или нескольких близких
страницах.
Если же нужны какие-то условия ускоряющие выбор остатков
например по конкретному товару то нужно взвешено выбирать между новым индексом или скоростью получения
остатка на любую дату.

Z1 писал(а) 26. Ноября 2008 :: 14:34:

Fill Factor. Рекомендую ознакомиться в BOL.