SQL Server: схема первичного ключа в основном ориентирована, но иногда целочисленные типы - PullRequest
Новая
       24

SQL Server: схема первичного ключа в основном ориентирована, но иногда целочисленные типы

1 голос
/ 14 мая 2010

ОК, это может быть глупый вопрос, но ...

Я унаследовал проект, и мне поручено изучить отношения первичного ключа.

В проекте широко используются гиды. Я говорю «в значительной степени», потому что есть примеры, когда в таблицах используются целочисленные типы для отражения перечислений. Например, dbo.MessageFolder имеет MessageFolderId типа int для отражения 

public emum MessageFolderTypes
{
  inbox = 1,
  sent = 2, 
  trash = 3, 
  etc...
}

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

Должен ли я заботиться о том, чтобы схема PK была пятнистой? Это не правильно, но действительно ли это важно? Если это может создать проблему, как мне ее обойти (я действительно не могу переместить все PK для ввода int без серьезной работы, и я никогда не слышал о перечислениях, имеющих значения guid)?

Спасибо.

Ответы [ 3 ]

4 голосов
/ 14 мая 2010

В идеале вы бы отошли от GUID как PK, из-за производительности - но я понимаю, что это может быть невозможно.

Производительность GUID хорошо изложена здесь: Каковы улучшения производительности последовательного Guid по сравнению со стандартным Guid?

Я бы не стал беспокоиться о пятнистости, если вы используете самый маленький ключ, который у вас есть, то вы обязательно должны иметь несколько разных типов данных в качестве PK в БД (TinyInt / SmallInt / Int / BigInt).

2 голосов
/ 14 мая 2010

Что бы вы могли сделать для «быстрого выигрыша», это:

  • оставить первичный ключ как есть (преимущество: вам не нужно изменять ограничения ссылочной целостности)
  • но сделайте ваш первичный ключ GUID некластеризованным первичным ключом
  • поместите ключ кластеризации в отдельное поле - используйте то, что уже доступно, если есть полезное поле - или, если нет, используйте поле INT IDENTITY

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

Прочтите здесь, почему GUID в качестве первичного ключа (фактически: в качестве ключа кластеризации) - ужасно плохой выбор, и прочитайте здесь Дебаты о кластеризованном индексе - опять! Какой хороший ключ кластеризации должно быть как - в идеале:

  • узкий (как можно меньше байтов)
  • статический (никогда не меняется)
  • уникально (в противном случае SQL Server нужно будет «унифицировать» ваши записи, добавив к ним 4 байта)
  • постоянно увеличивается (во избежание дорогостоящих разбиений страниц и уменьшения индекса / фрагментации страницы)

INT IDENTITY - идеальный кандидат.

0 голосов
/ 14 мая 2010

Самое главное, что все ключи, необходимые для обеспечения целостности, применяются. Нет реальной причины, по которой один и тот же тип столбца должен использоваться в качестве ключа в каждой таблице. Предположительно, у вас есть и другие (естественные) ключи, навязанные уникальными ограничениями / индексами, и если это так, я ожидаю, что некоторые из них включают столбцы, которые не являются ни целыми числами, ни направляющими.

...