Недавно я начал новую работу и заметил, что все таблицы SQL используют тип данных GUID для первичного ключа.
В моей предыдущей работе мы использовали целые числа (Auto-Increment) для первичного ключа, и с моей точки зрения было намного легче работать.
Например, скажем, у вас есть две связанные таблицы; Product и ProductType - я мог бы легко перекрестно проверить столбец "ProductTypeID" обеих таблиц для определенной строки, чтобы быстро сопоставить данные в моей голове, потому что ее легко хранить число (2,4,45 и т.д.), В отличие от (E75B92A3- 3299-4407-A913-C5CA196B3CAB).
Дополнительное разочарование приходит от меня, желающего понять, как связаны эти таблицы, к сожалению, нет диаграммы базы данных: (
Многие говорят, что GUID лучше, потому что вы можете определить уникальный идентификатор кода С#, например, с помощью NewID(), не требуя SQL SERVER, чтобы это сделать - это также позволяет вам заранее знать, что такое идентификатор.... но я видел, что можно еще получить "следующее автоматически увеличиваемое целое число".
Подрядчик DBA сообщил, что наши запросы могут быть на 30% быстрее, если мы используем тип Integer вместо GUIDS...
Почему существует тип данных GUID, какие преимущества он действительно предоставляет?... Даже если его выбор у какого-то профессионала, должны быть веские причины, почему его реализовано?
В некоторых случаях GUID хороши как поля для идентификации:
GUID генерируются глобально уникальными, поэтому они подходят для таких сценариев.
Вопреки тому, что большинство людей здесь, кажется, проповедуют, я вижу, что 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 в качестве основного и кластеризованного ключа:
ВСЕГО: 25 МБ против 106 МБ - и это только на одной таблице!
Еще немного еды для размышлений - отличный материал от Кимберли Триппа - прочитайте его, прочитайте снова, переваривайте! Это действительно SQL Server индексирование евангелия.
Марк
INT
Преимущество:
Числовые значения (и, в частности, целые числа) лучше для производительности при использовании в соединениях, индексах и условиях. Числовые значения легче понять для пользователей приложений, если они отображаются.
Неудобство:
Если ваша таблица большая, вполне возможно, что она закончится, а после некоторого числового значения не будет использоваться дополнительная идентификация.
GUID
Преимущество:
Уникальный сервер.
Неудобство:
Значения строк не так оптимальны, как целочисленные значения для производительности при использовании в соединениях, индексах и условиях. Требуется больше места для хранения, чем INT.
кредит относится к: http://blog.sqlauthority.com/2010/04/28/sql-server-guid-vs-int-your-opinion/
Есть тысячи статей, посвященных использованию GUID в качестве ПК, и почти все они говорят то же самое, что говорит ваш подрядчик по DBA - запросы быстрее, чем GUID в качестве ключей.
Основное использование, которое я видел на практике (мы никогда не использовали их как PK), с репликацией. На странице MSDN для uniqueidentifier говорится примерно то же самое.
Он глобально уникален, поэтому каждая запись в вашей таблице имеет идентификатор GUID, который не используется ни в одном другом предмете в мире. Удобно, если вам нужна такая эксклюзивная идентификация (если вы реплицируете базу данных или комбинируете данные из нескольких источников). В противном случае ваша dba правильная - идентификаторы GUID намного больше и менее эффективны, чем целые числа, и вы можете ускорить свой дБ (30%? Возможно...)
Они в основном избавляют вас от более сложной логики использования
set @InsertID = scope_identity()