Бих се съгласил на 100% с вас - използвайки INT IDENTITY е много по-добре!
GUIDs може да изглеждат естествен избор за вашия първичен ключ - и ако наистина трябва, вероятно бихте могли да спорите да го използвате за PRIMARY KEY на таблицата. Какво силно бих препоръчал да не правите е да използвате колоната GUID като ключ за групиране , което SQL Server прави по подразбиране, освен ако изрично не му кажете да не го прави.
Наистина трябва да отделите два проблема:
1) първичният ключ е логическа конструкция - един от кандидат ключовете, който уникално и надеждно идентифицира всеки ред във вашата таблица. Това може да бъде всичко, наистина - INT, GUID, низ - изберете това, което има най-голям смисъл за вашия сценарий.
2) ключът за групиране (колоната или колоните, които определят „клъстерирания индекс“ в таблицата) – това е физическо нещо, свързано със съхранението, и тук малък, стабилен, непрекъснато нарастващ тип данни е най-добрият ви избор - INT или BIGINT като опция по подразбиране.
По подразбиране първичният ключ на таблица на SQL Server също се използва като ключ за клъстериране - но това не е необходимо да е така! Лично съм виждал огромни печалби в производителността при разделянето на предишния базиран на GUID първичен / клъстерен ключ на два отделни ключа - първичен (логически) ключ на GUID и ключ за групиране (подреждане) на отделен INT IDENTITY(1, 1) колона.
Като Кимбърли Трип - кралицата на индексирането - и други са заявявали много пъти - GUID като ключ за клъстериране не е оптимален, тъй като поради произволността си ще доведе до масивна фрагментация на страници и индекси и като цяло до лоша производителност.
Да, знам - има newsequentialid() в SQL Server 2005 и по-нови - но дори това не е наистина и напълно последователно и следователно също страда от същите проблеми като GUID - само малко по-малко забележими.
След това има още един проблем, който трябва да имате предвид:ключът за клъстериране на таблица ще бъде добавен към всеки един запис на всеки неклъстъриран индекс на вашата таблица също - така че наистина искате да сте сигурни, че е възможно най-малък. Обикновено INT с 2+ милиарда реда трябва да е достатъчен за по-голямата част от таблиците - и в сравнение с GUID като ключ за клъстериране, можете да си спестите стотици мегабайта място за съхранение на диска и в паметта на сървъра.
Бързо изчисление - използване на INT срещу GUID като основен и клъстерен ключ:
- Базова таблица с 1'000'000 реда (3,8 MB срещу 15,26 MB)
- 6 неклъстерирани индекса (22,89 MB срещу 91,55 MB)
ОБЩО:25 MB срещу 106 MB - и това е само на една маса!
Още малко храна за размисъл - отлични неща от Кимбърли Трип - прочетете го, прочетете го отново, смилайте го! Това наистина е евангелието за индексиране на SQL Server.
- GUID като ОСНОВЕН КЛЮЧ и/или клъстерен ключ
- Дебатът за групирания индекс продължава
- Непрекъснато нарастващ ключ за клъстериране - дебатът за клъстерирания индекс..........отново!
- Дисковото пространство е евтино - това е не точката!
