Guid vs INT - что лучше в качестве первичного ключа?

Я читаю о причинах использования или не Guid и int.

int меньше, быстрее, легко запоминается, сохраняет хронологическую последовательность. А что касается Guid, единственное преимущество, которое я нашел, это уникальность. В этом случае a Guid будет лучше, чем и int и почему?

Из того, что я видел, int не имеет недостатков, кроме предела числа, что во многих случаях не имеет значения.

Почему именно был создан Guid? Я на самом деле думаю, что у него есть цель, отличная от того, чтобы служить в качестве первичного ключа простой таблицы. (Любой пример реального приложения с помощью Guid для чего-то?)

(Guid = UniqueIdentifier) ​​на SQL Server

80 голосов | спросил BrunoLM 5 Jam1000000amWed, 05 Jan 2011 10:46:34 +030011 2011, 10:46:34

6 ответов


73

Это задано в разделе «Переполнение стека» здесь и здесь .

сообщение Джеффа объясняет много о плюсах и минусах использования GUID.

  

Преимущества GUID

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

Недопустимые GUID

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

Если вы уверены в производительности и не планируете реплицировать или объединять записи, используйте int и установите для него автоматическое увеличение ( идентификационное семя в SQL Server ). .

ответил CoderHawk 5 Jam1000000amWed, 05 Jan 2011 11:17:30 +030011 2011, 11:17:30
16

Если вы синхронизируете свои данные с внешним источником, постоянный GUID может быть намного лучше. Быстрый пример того, где мы используем GUID - это инструмент, который отправляется клиенту для обхода их сети и выполнения определенных классов автоматического обнаружения, хранения найденных записей, а затем все записи клиентов интегрированы в центральную базу данных назад на нашем конце. Если бы мы использовали целое число, у нас было бы 7,398 "1", и было бы намного сложнее отслеживать, какой из них был «1».

ответил TML 5 Jam1000000amWed, 05 Jan 2011 11:13:44 +030011 2011, 11:13:44
11

Я использовал гибридный подход с успехом. Таблицы содержат BOTH столбец первичного ключевого слова auto-increment integer id И столбец guid. guid может использоваться по мере необходимости, чтобы глобально однозначно идентифицировать строку, а id можно использовать для запросов, сортировки и идентификации человека в строке.

ответил rmirabelle 3 PMpFri, 03 Apr 2015 20:04:17 +030004Friday 2015, 20:04:17
1

В некоторых передовых практиках все еще упоминается, что вы должны использовать тип данных, который вмещает меньше памяти, чем весь набор значений, которые вы собираетесь использовать. Например, если вы используете его для хранения числа работодателей в малом бизнесе, и вряд ли вы достигнете 100, то никто не будет предлагать использовать значение bigint, в то время как int (даже smallint) будет делать.

Конечно, недостаток этого заключается в том, что «Скажи нет масштабируемости!»


Кроме того, я знаю, что это не полностью связано, но есть еще один фактор в этом отношении. Если не excesive, я обычно стараюсь рекомендовать использовать неавтогенерированный первичный ключ, если это имеет смысл. Например, если вы сохраняете информацию о драйвере, не беспокойтесь о создании нового автогенерированного столбца для «ID», просто используйте номер лицензии.

Я знаю, что это звучит очень очевидно, но я вижу, что его часто забывают.

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

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

Спасибо @VahiD за разъяснения.

ответил Alpha 6 AM00000040000002231 2011, 04:57:22
0

Еще одна вещь, с которой генерируются GUID. mrdenny правильно указал, что даже если используется newsequentialid (), перезапуск экземпляров приводит к тому, что новые значения начинаются с «дыр», оставшихся в предыдущей обработке. Еще одна вещь, которая влияет на «последовательные» GUID, - это сетевая карта. Если я правильно помню, UID NIC используется как часть алгоритма GUID. Если NIC заменен, нет никакой гарантии, что UID будет более высоким значением для сохранения последовательного аспекта вещей. Я также не уверен, что несколько сетевых адаптеров могут повлиять на назначение значений с использованием алгоритма.

Просто мысль, и я надеюсь, что правильно помню. Отличный день!

ответил bobo8734 2 Mayam18 2018, 00:12:09
-4

Используйте оба

Используйте int /Bigint для Первичного ключа, поскольку его легко поддерживать и использовать в качестве внешних ключей.

Но привяжите столбец к GUID , чтобы каждая строка также имела уникальный столбец

ответил Abdul Hannan Ijaz 5 Jpm1000000pmTue, 05 Jan 2016 15:58:17 +030016 2016, 15:58:17

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132