128-битов GUID (uniqueidentifier ) ключът разбира се е 4 пъти по-голям от 32-битов int ключ. Има обаче няколко ключови предимства:
- Няма проблем с „IDENTITY INSERT“ при обединяване на съдържание
- Ако използвате стойност COMB вместо NEWSEQUENTIALID(), получавате „безплатно“ клеймо за време INSERT. Можете дори да
SELECTот първичния ключ въз основа на диапазон от дата/час, ако искате с няколко фантастичниCAST()обаждания. - Те са уникални в световен мащаб, което се оказва доста удобно от време на време.
- Тъй като няма нужда да се проследяват знаци с висока вода, вашият BL слой може да присвои стойността, а не SQL Server, като по този начин елиминира стъпката на
SELECT scope_identity()за да получите първичния ключ след вмъкване. - Ако е дори отдалечено възможно да имате повече от 2 милиарда записа, ще трябва да използвате
bigint(64 бита) вместоint. След като направите това,uniqueidentifierе само два пъти по-голям отbigint. - Използването на GUID прави по-безопасно разкриването на ключове в URL адреси и т.н., без да се излагате на атаки „познайте идентификатора“.
- Между това как SQL Server зарежда страници от диск и как процесорите вече са предимно 64-битови, само защото числото е 128 бита вместо 32, не означава, че сравняването му отнема 4 пъти повече време. Последният тест, който видях, показа, че GUID са почти толкова бързи.
- Размерът на индекса зависи от колко колоните са включени. Въпреки че самите GUID са по-големи, допълнителните 8 или 12 байта може да са незначителни в сравнение с другите колони в индекса.
В крайна сметка изтласкването на малко предимство на производителността чрез използване на цели числа може да не си струва да загубите предимствата на GUID. Тествайте го емпирично и решете сами.
Лично аз все още използвам и двете, в зависимост от ситуацията, но решаващият фактор никога не се е свеждал до производителността в моя случай.
