Первичный ключ составного индекса против уникального первичного ключа с автоматическим приращением

Question

У нас есть таблица транзакций длиной более 111 м, которая имеет кластерный составной первичный ключ ...

RevenueCentreID  int
DateOfSale       smalldatetime
SaleItemID       int
SaleTypeID       int

... в базе данных SQL 2008 R2.

В ближайшее время мы собираемся урезать и снова заполнить таблицу для проекта архивации, поэтому возможность получить правильные индексы появится после того, как таблица будет усечена. Было бы лучше сохранить составной первичный ключ или мы должны перейти к уникальному первичному ключу с автоматическим приращением?

Большая часть поиска в таблице выполняется с использованием столбцов DateOfSale и RevenueCentreID. Мы также часто присоединяемся к столбцу SaleItemID. Мы почти никогда не используем столбец SaleType, фактически он включен только в первичный ключ для уникальности. Мы не заботимся о том, сколько времени потребуется для вставки и удаления новых данных о продажах (сделанных за ночь), а скорее о скорости возврата отчетов.

Answer 1

В узнали, что вы хотите и нуждаетесь как в естественном ключе, так и в суррогатном ключе.

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

Таким образом, в вашем случае суррогатный автоинкрементный ключ хорош тем, что он помогает сохранить все строки данных в такте. А естественный ключ DateOfSale, RevenueID и, возможно, ClientID мог бы стать отличным способом предотвращения хранения дублированных записей и ускорения запросов, поскольку вы можете индексировать естественный ключ.

Answer 2

Суррогатный ключ здесь не имеет смысла.Я предлагаю кластерный первичный ключ для перечисленных столбцов и индекс для SaleItemID.

Answer 3

Если вас не волнует скорость вставок и удалений, то вам, вероятно, нужно несколько индексов, которые точно нацелены на запросы.

Вы можете создать первичный ключ с автоинкрементом, как вы предлагаете, а также создать индексы, необходимые для покрытия запросов отчетов. Создайте уникальное ограничение для столбцов, которые у вас есть в ключе, чтобы обеспечить уникальность.

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

Практическое правило - вы можете определять столбцы для индексации, а также «включать» столбцы.

Если в вашем отчете есть столбец OrderBy или Where, то вам нужно определить индекс по ним. Любые другие поля, возвращаемые в select, должны содержать столбцы.