Первичный ключ в базе данных Azure SQL

Question

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

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

1. Последовательные идентификаторы GUID хороши, если вы используете на компьютере сервера SQL Предпосылки - последовательные идентификаторы GUID, которые создаются всегда будут уникальными. Однако на Azure это уже не так. Как обсуждалось в this thread, оно больше не поддерживается; и их генерация также является плохой идеей, так как она становится единственной точкой отказа, и она не будет гарантирована уникальным образом на всех серверах. Я предполагаю, что последовательные подсказки не имеют смысла на Azure, поэтому я должен придерживаться регулярных указаний. Это верно?

2. Столбцы типа Guid являются плохими кандидатами для кластеризации. Но this article утверждает, что это не так на Azure, и this one предлагает противоположное! Во что я должен верить? Должен ли я просто сделать свой первичный ключ ориентиром и оставить его кластеризованным (поскольку это по умолчанию для первичных ключей); или я не должен кластеризовать его и выбрать другой столбец для кластеризации?

Спасибо за понимание!

Answer 1

Последовательные генерируемые контуры всегда будут уникальными. Однако на Azure это уже не так.

Посмотрите на нижней части этого поста здесь - http://blogs.msdn.com/b/sqlazure/archive/2010/05/05/10007304.aspx

Проблема с Guid (которые полагаются на NEWID()) является то, что они будут распределены случайным образом, который имеет проблемы с производительностью, когда речь идет о применении кластерного индексировать их.

Что я предлагаю, так это то, что вы используете GUID для своего Первичного ключа. Затем удалите кластерный индекс по умолчанию из этого столбца. Примените кластеризованный индекс к другому полю вашей таблицы (т. Е. Созданной дате), чтобы записи последовательно или последовательно индексировались по мере их создания. А затем примените некластеризованный индекс к столбцу PK Guid.

Скорее всего, это будет отлично от * SELECT * FROM TABLE WHERE Id = "точка зрения для возвращения одиночных экземпляров.

Точно так же, если вы возвращение списков или диапазонов записей для отображения в список, если вы specifiy порядок по умолчанию, CreatedDate, ваш кластерный индекс будет работать для этого

Answer 2

Учитывая следующий

1. Sql Azure требуется кластерный индекс для выполнения репликации. Примечание, индекс не должен быть уникальным. http://blogs.msdn.com/b/sqlazure/archive/2010/05/12/10011257.aspx

2. Преимущество кластерного индекса заключается в том, что запросы диапазона по индексу выполняются оптимально с минимальными запросами.

3. Недостатки кластерного индекса состоят в том, что если данные будут добавлены в порядке упорядочения, может произойти разделение страницы, и вставки могут быть относительно медленными.

Реферирование выше, я предлагаю следующее

1. Если у вас есть реальный диапазон ключей необходимо запрашивать от, например, дата, порядковый номер и т.д.
   1. создать (уникальный/не-уникальный) кластеризованный индекс для этого ключа.
   2. создать дополнительный уникальный указатель с идентификаторами GUID домена.
2. Если реального диапазона ключей нет, просто создайте уникальный кластеризованный индекс с идентификаторами GUID домена. (Накладные расходы на добавление фальшивого ненужного кластеризованного индекса были бы скорее помехой, чем помощью.)