Это плохая идея использовать GUID в качестве первичных ключей в MS SQL? - PullRequest
24 голосов
/ 11 февраля 2009

У нас есть система, которая использует UniqueIdentifier в качестве первичного ключа каждой из таблиц. До нашего сведения дошло, что это плохая идея. Я видел подобный пост на эту тему, но меня интересует производительность MS SQL и другие потенциальные проблемы, с которыми я могу столкнуться из-за этого решения.

Ответы [ 12 ]

25 голосов
/ 11 февраля 2009

Есть плюсы и минусы:

Эта статья охватывает все.

GUID Плюсы

  • Уникальный для каждой таблицы, каждой базы данных, каждого сервера
  • Позволяет легко объединять записи из разных баз данных
  • Позволяет легко распределять базы данных по нескольким серверам
  • Вы можете генерировать идентификаторы где угодно, вместо того, чтобы обращаться к базе данных туда и обратно
  • В большинстве сценариев репликации все равно требуются столбцы GUID

GUID Минусы

  • Это в 4 раза больше, чем у традиционного 4-байтового значения индекса; это может иметь серьезные последствия для производительности и хранения, если вы не будете осторожны
  • Громоздко для отладки (где userid = '{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
  • Сгенерированные идентификаторы GUID должны быть частично последовательными для лучшей производительности (например, newsequentialid () в SQL 2005) и для возможности использования кластеризованных индексов
17 голосов
/ 11 февраля 2009

Я написал пост об этой прошлой неделе с некоторым кодом, чтобы показать вам, что происходит: Простой код, чтобы показать разницу между Newid и Newsequentialid

В основном, если вы используете newid () вместо Newsequentialid (), вы получите ужасные разбиения страницы, если ваш PK является кластеризованным индексом (который будет по умолчанию)

15 голосов
/ 11 февраля 2009

Лично я бы использовал int или bigint для PK, но просто вставил бы еще один столбец «Guid» для тех ситуаций, когда вам нужен неосуществимый «ключ» для этой записи, и генерировал бы Guid при вставке строки .

4 голосов
/ 11 февраля 2009

Будет плохо, если вам нужно будет выполнять объединения на больших сетах (скажем, на 100 000). Был там, страдал этим.

Позже Редактирование: я также столкнулся с еще худшим провалом (не могу назвать это "подходом"): хранение GUID в столбцах char (36) !!

3 голосов
/ 11 февраля 2009

Джимми Нильссон написал фантастическую статью о GUID против INT и комбинированных GUIDS . Выводы ... не бойтесь GUID ... в любом случае, составные направляющие.

3 голосов
/ 11 февраля 2009

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

Как уже было сказано, большим недостатком является разделение страниц, которое произойдет, если ваш PK будет кластеризованным индексом; однако, вы можете решить это двумя способами. Вы можете использовать NewSequentialId () или вы можете установить PK как некластеризованный. Я бы порекомендовал вам создать базу данных на основе ваших требований к данным, и если вам нужен GUID, используйте ее, а затем оптимизируйте ее. И проверить его производительность в вашей среде.

1 голос
/ 11 февраля 2009

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

1 голос
/ 11 февраля 2009

Это "плохая" идея. Это может быть медленно. Вам это не очень хорошо для быстрого поиска по индексам. Единственный реальный момент времени, в котором мы используем GUID или уникальные идентификаторы, - это когда нам необходимо поддерживать элементы данных, связанные между базами данных, обычно, когда у нас есть база данных сервера и локальная база данных для приложения (для отключенных систем). У вас действительно нет другого способа держать вещи вместе, кроме гидов. Для индексов и первичных ключей вы хотите использовать целочисленное значение и пытаться связать вещи с таблицами ассоциаций, а не использовать повсеместно направляющие.

0 голосов
/ 11 февраля 2009

Если вы делаете какие-либо репликации базы данных, GUID - ваш лучший друг!

0 голосов
/ 11 февраля 2009

Я бы не сказал, что это плохо , само по себе. Я говорил со многими людьми, которые клянутся этим, хотя я нахожу это немного многословным. Я согласен с routeNpingme и скажу, что вы должны использовать обычное целое число для идентификатора, но также указывать GUID (который вам нужен для репликации в любом случае) "на всякий случай"

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...