Aleksey-Kно не нашел там (если читать все обсуждение)противоречий с тем, что я сказал: (для кластерного индекса выбираю, КАК ПРАВИЛО, PK (Primary Key), тип данных Integer со свойством IDENTITY(1,1)).
Жаль, но на нет, и суда нет...
Эта рекомендация, как правило, неверная, и было бы Вашим делом, если бы не предлагали следовать такому подходу остальным.

P.S. Только не надо прикрываться банальностями, типа Aleksey-KНет правил без исключений.., но они (исключения) только подтверждают правила.Исключения, подтверждающие правила - это, IMHO, чушь, обычно говорит о том, что правило пора менять.

P.P.S. Ничего личного.

Aleksey-KРекомендация по поводу PK Identity(1,1) INTEGER на самом деле очень верная. Я уверен,что 90 процентов посетителей этого сайта так и поступают, и если Вы не входите в их число, значит Вы теоретик.
Массовость мнения не есть доказательство правильности этого мнения, не говоря уж о таком обобщении - 90%, да еще - сайта. Опять ведь общие слова...
На этом форуме тема кластерных индексов поднимается периодически, в пределах месяца, максимум - двух. Каждый раз несутся одни и те же голословные, невесть откуда взявшиеся утверждения. Большинству более-менее грамотных проектировщиков БД эта тема уже просто надоела, повторять одно и то же - не самое интересное занятие. Если Вам и вправду интересна эта тема, то поищите на этом форуме темы, связанные с кластерным индексом. Поверьте, это будет очень познавательно, особенно если учесть, что Ваш опыт, судя по всему, идет от FoxPro и dbf-файлов...

Aleksey-KКак правило, таблица факторов (не справочник) имеет несколько индексов для покрытия различных запросов и длинный кластерный ключ приведет в существенному росту всех остальных индексов. Есть случаи, когда кластерный индекс используют не для описанного мною (и BOL) варианта, но , как правило, эти таблицы и не имеют сурогатного PK (диапазон дат, как правило)Во-первых, ответьте сами себе на вопрос, зачем кластерный индекс существует в принципе, неужели только для того, чтобы данные в таблице сохранялись в том же порядке, в котором они добавлялись ? И факт того, что в MSSQL значение кластерного ключа включаются в остальные индексы (хорошо, что Вы об этом знаете) ровным счетом ничего не меняет. Из того, что желательно делать его как можно меньше, совершенно не следует, что clustered PK Identity(1,1) INTEGER - это лучший вариант. И особенно для таблицы фактов, Вы ведь ее имели в виду, нет ?

Aleksey-K1. Практически все они утверждают, что максимальную эффективность дает использование кластерного индекса по тем полям, по которым выполняется поиск по диапазону значения. В реальном приложении такие поиски необходимо выполнять в 70% по полям типу дата (например: с 1.1.2005 по 21.01.2005). Вот по этим полям я, конечно, и создаю кластерный индекс, а для PK использую некластерный.Дело даже не столько в диапазоне, это просто естественное следствие из главной задачи кластерного индекса - минимизация операций чтения при типичных выборках данных. В некотором смысле можно даже считать кластерный индекс аналогом разбиения на partition.
Иногда можно получить дополнительный бонус, за счет уменьшения борьбы за страницу между конкурирующими процессами. В этом смысле дата документа может оказатся далеко не самым удачным вариантом, по крайней мере, не первым полем в кластерном индексе.

Aleksey-KИногда, имеет смысл кластерный индекс использовать и для числового поля (в вашем цитате: sales_quantity BETWEEN 500 and 1000), но... это уже не очень легко выполнить на практике. Как правило, в таблице факторов (например, документы), дата одна, а цифровых полей несколько (кол-во, суммы в рублях и суммы в валюте и т.п.) и по всем надо производить поиск типа: «sales_quantity BETWEEN 500 and 1000». По какому полю будете делать индекс, он ведь один!Вы опять про таблицу факторов, может все таки фактов ?
IMHO, один из неудачных примеров, полагаю он был сделан таковым только для доходчивости. Делать кластерный индекс по предположительно часто меняющимся данным - не самая хорошая идея. И вообще делать индексы по числовым данным - кол-во, суммы, цены и т.п. (исключая целочисленные идентификаторы, обычно - суррогатные), в большинстве случаев смысла нет, разве что в приложениях OLAP, но это совсем другая песня.

Aleksey-KСвое утверждение я делаю исходя из более чем 12-летнего опыта разработки приложений управления базами данных, а не цитат из умных, но иногда, практически бесполезных книг.Надо было для веса упомянуть MCP и MCSE :) За это время можно было бы понять, когда, как и зачем применять кластерный индекс. Хорошо подобранный кластерный индекс может позволить отказаться от ряда некластерных.

Aleksey-KЛегко посоветовать использовать кластерный индекс для всех BETWEEN, а на практике…. Один индекс для всех !Это кто Вам такое советовал ? Правильный выбор кластерного индекса совсем не подразумевает что его надо "раскорячить" на все диапазоны, хотя определенная иерархия может наличествовать, но что и на каком уровне опять же определяется типичными запросами к таблице.

Aleksey-K2. Как это реально не выполняется поиск по суррогатным ключам!!! Да большинство запросов в моих хранимых процедурах (да полагаю и не только в моих) содержат многочисленные JOIN ... . Это разве не поиск по PK и FK?!Каждая таблица факторов может содержать массу FK, и в запросе, как правило, они все переходят в JOIN. Или вы считаете, что MERGE JOIN менее эффективен, чем NESTED LOOP (я и об этом знаю, а вы !?)Может Вы даже знаете, что MERGE считается более дорогим, чем NESTED LOOP ? И в каких случаях он применим ? Это называется "распальцовкой", а не аргументом...

Aleksey-Kоскорбления.Именно по этому и была сделана оговорка - ничего личного, претензии были к смыслу, а не к личности. А Вы, к сожалению, восприняли происходящее, как наезд на Вас, как на личность.

Aleksey-KПолагаю, что данный спор стал бесполезным ... предлагаю его закончить. Если бы не было такой рекомендации остальным Aleksey-Kдля кластерного индекса выбираю, как правило , PK (Primary Key), тип данных Integer со свойством IDENTITY(1,1) и НИКОГДА не имею, описанную Вами ситуацию, то не было бы и повода...

Aleksey-KНельзя один общий (а поэтому не очень умный) совет - "Используйте ВСЕГДА кластерный индекс на PK" подменять другим, не менее общим (следовательно, не более умным) - "НИКОГДА не используете кластерный индекс для суррогатных PK"Оба утверждения взяты непонятно откуда или что-то пропустил в ходе дискуссии, можете привести ссылки ? Кластерный совсем необязательно должен быть PK, но может им быть.

P.S. Фактически - уже флейм, продолжать в таком духе не вижу смысла, делайте, как хотите, только другим не внушайте иллюзий...

С уважением к Вашим регалиям.

ShurgenzВерно ли я мыслю?Логика есть, только не забывайте о том, что в MSSQL кластерный индекс рекомендуется делать уникальным. Если это не сделаете сами, то сервер сделает это за Вас, добавляя, не несущий никакой другой смысловой нагрузки, кроме "уникализации", "хвост".
Это можно сделать, например, путем включения PK в конец кластерного индекса, что-то вроде (Rng10, ID), или других значений, обеспечивающих "уникализацию". В общем, экспериментируйте...

ChA ShurgenzВерно ли я мыслю?Пара добавлений, на всякий случай, к предыдущему посту.
1. Явная "уникализация" кластерного индекса обязательно должна сопровождаться словом UNIQUE в его определении. Т.е., типа Это, естественно, не нужно, если таковой индекс определяется как ограничение вида PRIMARY KEY или UNIQUE, для них достаточно просто указать, что они CLUSTERED.
2. Значения кластерного индекса будут также включатся во все некластерные индексы или ограничения, поэтому кроме минимизации размера кластерного "значения" (в пределах ~десятка байт, желательно, но не критично), хорошо чтобы "хвост", добавляемый для "уникализации" был "удачным", т.е., с наибольшей вероятностью востребованным (covered)...