SQL Server - Структурированный индексный указатель для словаря

Question

Хотелось бы посоветовать это. У меня есть таблица, где я хочу отслеживать объект и список ключей, связанных с объектом. Пример:

OBJECTID ITEMTYPE ITEMKEY 
-------- -------- ------- 
1   1   THE 
1   1   BROWN 
1   2   APPLE 
1   3   ORANGE 
2   2   WINDOW 

Оба OBJECTID и ItemKey имеют высокую селективность (то есть ObjectId и ItemKey очень разнообразны). Мой доступ двумя способами:

• По OBJECTID: Каждый раз, когда объект изменяется, список ключевых изменений, чтобы ключ необходим основанный на OBJECTID. Изменения происходят часто.

• ITEMKEY: Это для поиска по ключевым словам, а также часто бывает.

Так что я, вероятно, нужно два ключа, и выбрать один для кластерного индекса (тот, который чаще обращались, или там, где я хочу скорость быть, потому что теперь предположим, я буду приоритеты ObjectId для кластерный). Меня смущает то, как я должен его проектировать.

Мои вопросы, что лучше:

а) Кластерный индекс (OBJECTID, ItemType, ItemKey), а затем индекс (ItemKey). Я обеспокоен тем, что, поскольку кластерный индекс настолько велик (2 ints, 1 строка), индекс будет большим, потому что все элементы индекса должны были вернуться к кластерному ключу.

b) Создайте новый столбец с запущенным идентификатором DIRECTORYID (целое число) в качестве первичного ключа и кластерного индекса и объявите два индекса для (OBJECTID, ITEMTYPE, ITEMKEY) и просто (ITEMKEY). Это позволит свести к минимуму пространство индекса, но с более высокими затратами на поиск.

c) Кластерный индекс (OBJECTID, ITEMTYPE, ITEMKEY) и материализованный вид (ITEMKEY, ITEMTYPE, OBJECTID) на нем. Моя логика заключается в том, что это позволяет избежать ключевого поиска и по-прежнему будет столь же большим, как индекс с поиском в: а), по стоимости более высоких накладных расходов.

d) Err ... может быть, есть лучший способ, учитывая требования?

Заранее спасибо, Andrew

Answer 1

Если когда-либо возможно, старайтесь держать кластерный ключ как можно, так как он также будет добавлен ко всем некластеризованным индексам на вашем столе.

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

Так что из представленных вами вариантов я лично выбрал бы б) - почему ???

Добавление суррогатной DirectoryID удовлетворят все важные критерии для ключа кластеризации:

• небольшого
• стабильной
• уникального
• постоянно увеличивающегося

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

См. Kimberly Tripp's outstanding blog post по основным критериям выбора хорошего ключа кластеризации на таблицах SQL Server - очень полезно и полезно!

Чтобы удовлетворить ваши требования к запросу, я бы добавил два некластеризованных индекса, один на ObjectID (возможно, включая другие часто используемые столбцы), а другой - на ItemKey для поиска по ключевому слову.