Ключевой тип данных для большого объема SQL Server 2008?

Question

Я в процессе проектирования базы данных для больших объемов данных, и мне было интересно, какой тип данных использовать для первичных ключей?

Будет выполнено разбиение таблиц, а база данных будет в конечном итоге кластеризована и обеспечит горячее переключение на альтернативные центры обработки данных.

EDIT

---

Таблицы - продумайте систему чата для нескольких периодов времени и множество вещей, чтобы общаться с несколькими пользователями, болтающими о периоде времени и вещах.

Я имею в виду экспоненциальные проблемы - то есть что-то может генерировать миллиарды строк за небольшой промежуток времени. то есть прежде чем мы сможем изменить базу данных или администратора базы данных, делая вещи администратора базы данных

Марк - я разделяю ваше понимание GUID - мне не нравится кодирование с летающими GUID.

Answer 1

Имея лишь небольшую информацию, которую вы предоставили, я бы порекомендовал использовать BigInt , который принесет вам до 9 223 372 036 854 775 807, число, которое вы вряд ли когда-либо превысите. (Не начинайте с INT и думайте, что вы можете легко изменить его на BigInt, когда вы превысите 2 миллиарда строк. Это возможно (я это сделал), но это может занять очень много времени и привести к значительным сбоям в работе системы.)

У Кимберли Триппа есть отличная серия статей в блогах ( GUID в качестве ПЕРВИЧНЫХ КЛЮЧЕЙ и / или ключа кластеризации и Дебаты по кластерному индексу продолжаются ) по вопросу создания кластеризованных индексов и выбора первичного ключа (связанные проблемы, но не всегда точно такие же). Она рекомендует, чтобы кластерный индекс / первичный ключ был:

1. Уникальный (в противном случае он бесполезен в качестве ключа)
2. Узкий (ключ используется во всех некластеризованных индексах и в отношениях внешнего ключа)
3. Статический (вам не нужно изменять все связанные записи)
4. Всегда увеличивается (поэтому новые записи всегда добавляются в конец таблицы, и их не нужно вставлять в середину)

Если вы используете BigInt в качестве растущей идентичности в качестве своего ключа и своего кластерного индекса, это должно удовлетворять всем четырем из этих требований.

Редактировать: статья Кимберли, о которой я упоминал выше ( GUID в качестве ПЕРВИЧНЫХ КЛЮЧЕЙ и / или ключа кластеризации ), говорит о том, почему (сгенерированный клиентом) GUID является плохим выбором для кластеризации ключ:

Но GUID, который не является последовательным - как тот, который имеет свои ценности генерируется в клиенте (с использованием .NET) ИЛИ, сгенерированный функцией newid () (в SQL Server) может быть ужасно плохо выбор - в первую очередь из-за фрагментация, которую он создает в базовый стол, но и из-за его размер. Это излишне широкий (это 4 в разы шире, чем основанная на Int идентичность - который может дать вам 2 миллиарда (на самом деле, 4 миллиарда) уникальных строк). А также, если вам нужно более 2 миллиардов всегда можно пойти с большой буквы (8 байт int) и получите 263-1 строки.

В SQL есть функция NEWSEQUENTIALID (), которая позволяет генерировать последовательные идентификаторы GUID, позволяющие избежать проблемы фрагментации, но при этом они по-прежнему сталкиваются с проблемой ненужной ширины.

Answer 2

int имеет тенденцию быть нормой, если вам не нужен огромный объем данных, и имеет преимущество работы с IDENTITY и т. Д .; Guid имеет некоторые преимущества, если вы хотите, чтобы числа были не угадываемыми или экспортируемыми, но если вы используете Guid (если вы сами не сгенерируете его как «расчесанный»), вы должны убедиться, что он не кластеризован (индекс это не ферма), так как она не будет инкрементной.

Answer 3

Вы всегда можете выбрать int , но с учетом вашего разбиения / кластеризации я бы посоветовал вам изучить uniqueidentifier , который будет генерировать глобально уникальные ключи.

Answer 4

Я думаю, что int будет очень хорош для этого.

Диапазон INTEGER - от 2147483648 до 2147483647.

также вы можете использовать UniqueIdentifier (GUID), но в этом случае

• ограничение размера строки таблицы в MSSQL
• память + память. Представьте, что у вас есть таблицы с 10000000 строк и ростом
• гибкость: для INT доступны операторы T-SQL, например>,
• GUID не оптимизирован для запросов ORDER BY / GROUP BY и для запросов диапазона в целом