SQL GUID Vs Integer

Ответ 1

В некоторых случаях GUID хороши как поля для идентификации:

• Если у вас несколько экземпляров SQL (разные серверы), и вам нужно комбинировать различные обновления позже, не затрагивая ссылочную целостность
• Отключенные клиенты, которые создают данные - таким образом, они могут создавать данные, не беспокоясь о том, что поле ID уже выполнено.

GUID генерируются глобально уникальными, поэтому они подходят для таких сценариев.

Ответ 2

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

GUID могут показаться естественным выбором для вашего основного ключа - и, если вы действительно должны, вы, вероятно, можете поспорить, чтобы использовать его для ПЕРВИЧНОГО КЛЮЧА таблицы. То, что я настоятельно рекомендовал не делать, использует столбец GUID как ключ кластеризации, который SQL Server делает по умолчанию, если только вы не указали это не так.

Вам действительно нужно оставить две проблемы:

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

• ключ кластеризации (столбец или столбцы, определяющие "кластеризованный индекс" в таблице) - это связанная с физическим хранением вещь, а здесь небольшая, постоянно возрастающий тип данных - ваш лучший выбор - INT или BIGINT в качестве опции по умолчанию.

По умолчанию первичный ключ в таблице SQL Server также используется в качестве ключа кластеризации, но это не обязательно так! Я лично видел значительный прирост производительности при распаде предыдущего основного/кластерного ключа на основе GUID на два отдельных ключа - основной (логический) ключ в GUID и ключ кластеризации (упорядочения) на отдельной INT IDENTITY (1, 1).

Как Kimberly Tripp - Королева Индексации - и другие заявили много раз - GUID, поскольку ключ кластеризации не является оптимальным, поскольку из-за его случайности это приведет к массивной фрагментации страниц и индексов и, как правило, к плохой производительности.

Да, я знаю - там newsequentialid() в SQL Server 2005 и выше - но даже это не является поистине и полностью последовательным и, следовательно, также страдает от тех же проблем, что и GUID, - это немного менее заметно. Кроме того, вы можете использовать его только по умолчанию для столбца в своей таблице - вы не можете получить новый последовательный GUID в коде T-SQL (например, триггер или что-то еще) - еще один главный недостаток.

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

Быстрый расчет - использование INT против GUID в качестве основного и кластеризованного ключа:

• Базовая таблица с 1'000'000 строк (3,8 МБ против 15,26 МБ)
• 6 некластеризованных индексов (22,89 МБ против 91,55 МБ).

ВСЕГО: 25 МБ против 106 МБ - и это только на одной таблице!

Еще немного еды для размышлений - отличный материал от Кимберли Триппа - прочитайте его, прочитайте снова, переваривайте! Это действительно SQL Server индексирование евангелия.

• GUID как ключ PRIMARY KEY и/или кластеризованный ключ
• Обсуждение кластерного индекса продолжается
• Постоянно растущий ключ кластеризации - обсуждение кластерного индекса.......... снова!

Марк

Ответ 3

INT

Преимущество:

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

Неудобство:

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

GUID

Преимущество:

Уникальный сервер.

Неудобство:

Значения строк не так оптимальны, как целочисленные значения для производительности при использовании в соединениях, индексах и условиях. Требуется больше места для хранения, чем INT.

кредит относится к: http://blog.sqlauthority.com/2010/04/28/sql-server-guid-vs-int-your-opinion/

Ответ 4

Есть тысячи статей, посвященных использованию GUID в качестве ПК, и почти все они говорят то же самое, что говорит ваш подрядчик по DBA - запросы быстрее, чем GUID в качестве ключей.

Основное использование, которое я видел на практике (мы никогда не использовали их как PK), с репликацией. На странице MSDN для uniqueidentifier говорится примерно то же самое.

Ответ 5

Он глобально уникален, поэтому каждая запись в вашей таблице имеет идентификатор GUID, который не используется ни в одном другом предмете в мире. Удобно, если вам нужна такая эксклюзивная идентификация (если вы реплицируете базу данных или комбинируете данные из нескольких источников). В противном случае ваша dba правильная - идентификаторы GUID намного больше и менее эффективны, чем целые числа, и вы можете ускорить свой дБ (30%? Возможно...)

Ответ 6

Они в основном избавляют вас от более сложной логики использования

set @InsertID = scope_identity()