Использование INT или GUID в качестве первичного ключа

Question

Я пытался создать столбец ID на SQL-сервере VB.net, который обеспечивал бы последовательность чисел для каждой новой строки, созданной в базе данных. Поэтому для создания столбца ID я использовал следующий метод.

select * from T_Users 
ALTER TABLE T_Users  
ADD User_ID INT NOT NULL IDENTITY(1,1) Primary Key 

Затем я зарегистрировал несколько имен пользователей в базе данных, и это сработало отлично. Например, первые шесть строк будут 1,2,3,4,5,6. Затем я зарегистрировал еще 4 пользователей в следующий день, но на этот раз идентификационные номера переместились с 6 на A очень большое число, например: 1,2,3,4,5,6,1002,1003,1004,1005. Затем через два дня я зарегистрировал еще двух пользователей, а новые строки - 3002,3004. Поэтому мой вопрос заключается в том, почему он пропускает такое большое количество через день, когда я регистрирую пользователей. Является ли техника, я использовал для создания последовательности неправильно? Если это неправильно, кто-нибудь может рассказать мне, как это сделать правильно? Теперь, когда я разочаровался в технике, описанной выше, я попытался использовать последовательно генерируемые значения GUID. Последовательность значений GUID была сгенерирована штрафом. Однако единственным недостатком является то, что он генерирует очень длинные номера (в 4 раза больше размера INT). Мой вопрос здесь заключается в том, что использование GUID имеет какое-либо существенное преимущество перед INT?

С уважением,

Answer 1

Потенциал роста GUIDs:

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

Даунсайд GUIDs:

Guids, как первичные ключи могут иметь влияние на производительности БД, так как для кластерного первичного ключа, то DB хочет сохранить строки в порядке значений ключа. Но это означает много вставок между существующими записями, потому что GUID будут случайными.

Использование столбца IDENTITY не страдает от этого, потому что следующая запись, как гарантируется, имеет самое высокое значение, и поэтому каждая строка будет всегда прикрепляться к концу каждый раз. Не должно произойти повторное перемещение.

Существует компромисс, который должен генерировать псевдо-GUID, что означает, что вы ожидаете столкновения клавиш каждые 70 лет или около того, но очень сильно помогает индексировать.

Другие недостатки в том, что а) они занимают больше места для хранения, и б) реальная боль, чтобы написать SQL против, то есть гораздо проще набрать UPDATE TABLE SET FIELD = 'value' where KEY = 50003 чем UPDATE TABLE SET FIELD = 'value' where KEY = '{F820094C-A2A2-49cb-BDA7-549543BB4B2C}'

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

EDIT:

Этот вопрос охватывает то, что я имел в виду псевдо-GUID. INSERTs with sequential GUID key on clustered index not significantly faster

В SQL Server 2005+ вы можете использовать NEWSEQUENTIALID(), чтобы получить случайное значение, которое должно быть больше, чем предыдущие. См. Здесь для получения дополнительной информации http://technet.microsoft.com/en-us/library/ms189786%28v=sql.90%29.aspx

Answer 2

Является ли техника, я использовал для создания последовательности неправильно?

Нет. Если что-либо, ваши навыки Google не несуществующие.Короткий взгляд на «пропуск значений Sql идентичности сервер» даст вам TON возвращений в том числе:

SQL Server 2012 column identity increment jumping from 6 to 1000+ on 7th entry

и каноническое:

Why are there gaps in my IDENTITY column values?

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

В частности: SQL Server предопределяет номера в 1000 блоков и - при перезапуске сервера (например, на вашей рабочей станции) остаток теряется.

http://www.sqlserver-training.com/sequence-breaks-gap-in-numbers-after-restart-sql-server-gap-between-numbers-after-restarting-server/-

Если вы вручную sqyuence вместо (новый нин SQL Server 2012), вы можете определить размер кэша для этого (pregeneration) и установите его на 1 - при стоимости чуть ниже производительности, когда вы делаете много вставок.

Мой вопрос здесь в том, что использование GUID имеет какое-либо существенное преимущество перед INT?

Да. У вас может быть намного больше строк с GUID, чем с int. Например, int32 ограничивается примерно 2 миллиардами строк. Для некоторых из нас это слишком мало (у меня есть таблицы в диапазоне 10 миллиардов) и даже 64 больших int ограничены. И по-настоящему zetabyte-база данных, вы должны использовать guid в последовательности, самостоятельно созданной.

Любой нормальный человек не видит разницы, поскольку все мы не имеем дело с таким количеством строк. И более крупный размер делает многое более медленным (больший размер ключа = большее пространство в индексах = более крупные индексы = больше памяти/io для той же операции). Плюс даже ваш последовательный идентификатор будет прыгать.

Почему не просто настроить ваши ожидания на самом деле - личность не должна быть без пробелов - или использовать последовательность с кэшем 1.