Ключі кластеризації int і bigint з використанням властивості identity

Якщо вас не турбує можливість вичерпання доступних значень, існуюча при використанні цілих (INT) або довгих цілих (BIGINT), я рекомендую завжди задіяти один з цих типів даних, а не GUID для сурогатного ключа кластеризації. Це дозволить виконувати вставку (INSERT) послідовно і реалізувати унікальну ідентифікацію рядків в таблиці при більш ефективному витрачанні простору і значно меншою мірою фрагментації.


INT і BIGINT поводяться однаково, тому обмежимося розглядом INT, тобто цілого дли ної 4 байт, а не 16 байт, як в прикладі з GUID. Побудуємо нову таблицю з довжиною рядка 1000, як в прикладі з GUID, і виконаємо вставку рядків 8, 9, 11 і 23, щоб порівняти результати (див. Лістинг 4).


Спочатку результати, отримані з GUID і INT, виглядають однаково (див. Екран 7).




Вийшло однією сторінкою менше (25% економії в порівнянні з варіантом GUID), тобто ступінь заповнення сторінок підвищилася. Однак при таких маленьких таблицях результати не уявляють особливого інтереса- адміністраторів баз даних більше турбує те, що відбувається, коли бази даних стають величезними і некерованими. Порівняємо, що вийшло з використанням кластерізованного індексу на основі GUID для 80000 рядків (див. Екран 8), з результатами для того ж кількості рядків, отриманими з ключем INT (див. Екран 9).




• 10000 сторінок на рівні листя при використанні кластерізованного індексу на основі INT проти 14712 сторінок - у випадку з GUID.
• Послідовні Групові індекси на основі INT практично не призводять до масштабної фрагментаціі- аналогічні результати виходять для BIGINT.
• Більш «вузький» індекс у вигляді B-дерева при використанні INT в порівнянні з GUID (в моєму прикладі: 36 проміжних
сторінок проти 66).


При проектуванні базової структури таблиці я б рекомендував уникати застосування GUID. Розгляньте варіанти INT або BIGINT стосовно передбачуваного масштабу (якщо точно відомо, що масштаб невеликий, розгляньте також SMALLINT (коротке ціле) як можливий варіант). Використання GUID збільшить пул доступних значень для унікальної ідентифікації рядків в таблиці, але це буде досягнуто ціною великих витрат обчислювальних ресурсів і шкоди для продуктивності. На мій погляд, краще додати додатковий стовпець, щоб вирішити проблему масштабу, але не вдаватися до GUID. Неекономно витрачання простору і фрагментація - достатні причини для того, щоб тримати таблиці і GUID на чималій відстані один від одного.

---

Набагато більше, ніж розвиток і реалізація технологій GUID, вас цікавить вся доступна інформація по такій темі, як проект мережі зв`язку? Що ж, в такому разі вам дійсно точно слід звернутися за допомогою до фахівців сайту https://svyaz-info.ru/ (https://svyaz-info.ru/). Досвідчені фахівці в цій галузі зможуть дати самі вичерпні відповіді на ваші питання і підготувати унікальний проект під мережі зв`язку.