GUID.и автоматический идентификатор в качестве первичного ключа в базах данных SQL - PullRequest
Новая
       27

GUID.и автоматический идентификатор в качестве первичного ключа в базах данных SQL

0 голосов
/ 20 июня 2010 
SELECT COUNT(*) FROM table_name;

Мой алгоритм:

  • чек
  • count + 1 - начальная точка нового первичного ключа
  • Затем продолжайте увеличиваться перед каждой операцией вставки

Но что это за GUID? Предоставляет ли SQL Server что-то, где он автоматически генерирует и увеличивает первичный ключ?

Ответы [ 4 ]

8 голосов
/ 20 июня 2010

Есть 3 варианта 

CREATE TABLE A
(
ID INT IDENTITY(1,1) PRIMARY KEY,
... Other Columns
)

CREATE TABLE B
(
ID UNIQUEIDENTIFIER DEFAULT NEWID() PRIMARY KEY,
... Other Columns
)

CREATE TABLE C
(
ID UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY,
... Other Columns
)

Одной из причин, по которой вы могли бы предпочесть С, а не В, было бы уменьшение фрагментации, если бы вы использовали идентификатор в качестве кластеризованного индекса .

4 голосов
/ 20 июня 2010

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

Например, «нормальный», первичный ключ IDENTITY - 

1   Jason
2   Jake
3   Mike

который при слиянии с другой базой данных выглядит как 

1   Lisa
2   John
3   Sam

будет сложно. Вам нужно перебрать некоторые столбцы, убедиться, что ваши FK в порядке и т. Д. Используя GUID, данные выглядят так, и их легко объединить: 

1FB74D3F-2C84-43A6-9FB6-0EFC7092F4CE    Jason
845D5184-6383-473F-A5D6-4DE98DBFBC39    Jake
8F515331-4457-49D0-A9F5-5814EE7F50BA    Mike    
CE789C89-E01F-4BCE-AC05-CBDF10419E78    Lisa
4D51B568-107C-4B63-9F7F-24592704118F    John
7FA4ED64-7356-4013-A78A-C8CCAB329954    Sam

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

1 голос
/ 20 июня 2010

Проблема с использованием счетчика, а затем счетом +1 в качестве ключа, заключается в том, что если вы удалите запись из середины, вы получите сгенерированный дубликат ключа. EG: 

Key   Data    
1     A          
2     B
3     C
4     D

теперь удалите B (количество становится 3) и вставьте E. Это попытается сделать новый первичный ключ равным 4, который уже существует. 

Key   Data    
1        A          
3        C
4        D   <--After delete count = 3 here
4        E   <--Attempted insert with key 4

Вы можете использовать первичный ключ и автоинкремент, чтобы убедиться, что у вас нет этой проблемы 

CREATE TABLE myTable
(
  P_Id int NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (P_Id)
)

Или вы можете использовать GUID. Принцип работы GUID заключается в создании 128-битного целого числа (представленного в виде шестнадцатеричной строки из 32 символов) 

Key                                      Data
24EC84E0-36AA-B489-0C7B-074837BCEA5D     A
.
.

В результате получается 2 ^ 128 возможных значений (на самом деле, больших), поэтому шансы создания аналогичных значений одним компьютером чрезвычайно малы. Кроме того, есть алгоритмы, которые помогут попытаться избежать этого. Таким образом, GUID также является хорошим выбором для ключа.

Что касается того, используете ли вы целое число или GUID, обычно зависит от приложения, политики и т. Д.

1 голос
/ 20 июня 2010

создать таблицу вашей таблицы (id int indentity (1,1) первичный ключ, col1 varchar (10))

автоматически создаст для вас первичный ключПроверьте GUID в T-SQL, прямо сейчас его нет.

...