Ключи кластеризации INT и BIGINT с использованием свойства IDENTITY
Содержание:
1. Непоследовательность GUID;
2. Ключи кластеризации 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, вас интересует вся доступная информация по такой теме, как проект сети связи? Что ж, в таком случае вам определенно точно следует обратиться за помощью к специалистам сайта http://www.svyaz-info.ru/ (http://www.svyaz-info.ru/). Опытные специалисты в данной области смогут дать самые исчерпывающие ответы на ваши вопросы и подготовить уникальный проект под сети связи.
1. Непоследовательность GUID;
2.
Если вас не беспокоит возможность исчерпания доступных значений, существующая при использовании целых (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).
Отдавайте предпочтение INT, BIGINT и SMALLINT
При проектировании базовой структуры таблицы я бы рекомендовал избегать применения GUID. Рассмотрите варианты INT или BIGINT применительно к предполагаемому масштабу (если точно известно, что масштаб невелик, рассмотрите также SMALLINT (короткое целое) в качестве возможного варианта). Использование GUID увеличит пул доступных значений для уникальной идентификации строк в таблице, но это будет достигнуто ценой больших затрат вычислительных ресурсов и ущерба для производительности. На мой взгляд, лучше добавить дополнительный столбец, чтобы решить проблему масштаба, но не прибегать к GUID. Неэкономное расходование пространства и фрагментация — достаточные причины для того, чтобы держать таблицы и GUID на почтительном расстоянии друг от друга.
Гораздо больше, чем развитие и реализация технологий GUID, вас интересует вся доступная информация по такой теме, как проект сети связи? Что ж, в таком случае вам определенно точно следует обратиться за помощью к специалистам сайта http://www.svyaz-info.ru/ (http://www.svyaz-info.ru/). Опытные специалисты в данной области смогут дать самые исчерпывающие ответы на ваши вопросы и подготовить уникальный проект под сети связи.
