Выбор подходящего первичного ключа для распределенной среды
Для обеспечения работы служб Sync Framework с таблицами, участвующими в добавочной синхронизации, требуется, чтобы каждая строка имела уникальный идентификатор При синхронизации клиента и сервера с помощью моментальных снимков это условие не является обязательным. Обычно строки идентифицируются по первичному ключу, который определен в серверной или одноранговой базе данных. В распределенных средах необходимо быть особенно внимательным при выборе типа столбца, используемого в качестве первичного ключа. Первичные ключи должны быть уникальными на всех узлах и не должны использоваться повторно. После удаления строки ее первичный ключ не должен использоваться для другой строки. Если первичный ключ используется более чем на одном узле, то может возникнуть конфликт первичных ключей. Это условие должно выполняться в любой распределенной среде и не является недочетом платформ Sync Framework. В этом разделе описано несколько подходов к выбору первичных ключей, а также указана степень их соответствия требованиям работы в распределенной среде.
Столбцы автоприращения (идентификаторов)
Архитекторы баз данных часто выбирают в качестве первичного ключа столбец автоприращения. Если для столбца задано свойство автоприращения (свойство IDENTITY в SQL Server), то для каждой записи при вставке в таблицу создается новое значение. Это значение вычисляется путем увеличения или уменьшения текущего (начального) значения на фиксированное число (шаг приращения) и присвоения результата вставляемой строке. Для столбцов автоприращения обычно используются компактные типы данных, например целые числа. Это приводит к снижению размера кластеризованного индекса, повышению эффективности операций соединения и уменьшению объема ввода-вывода при выполнении запросов к базовой таблице.
Однако свойства начального значения и шага приращения являются фиксированными величинами, которые могут быть выбраны из конечного числа значений, поэтому очень высока вероятность конфликта первичных ключей. Такой тип ключа подходит для способов кэширования данных только с загрузкой. В этом случае сервер или назначенный компьютер одноранговой сети должен быть единственным узлом, формирующим новые значения первичных ключей. Поэтому гарантируется уникальность этих значений во всех узлах топологии. Столбцы автоприращения подходят также для синхронизации только с передачей и двунаправленной синхронизации, если операции вставки выполняются лишь на одном узле. В этом случае операции вставки обычно производятся только на сервере или назначенном компьютере одноранговой сети, а операции обновления и, возможно, удаления выполняются на одном или нескольких клиентах. Если операции вставки необходимо выполнять на нескольких узлах, то следует выбрать один из прочих подходов, описанных далее в этом разделе.
Идентификаторы GUID
Использование идентификатора GUID (столбец uniqueidentifier в SQL Server) в качестве первичного ключа гарантирует уникальность чисел во всех узлах и исключает конфликты первичных ключей, которые могут возникать со столбцами автоприращения. Однако применение идентификатора GUID в первичном ключе может иметь следующие последствия.
Из-за большого размера данных (16 байт) размер кластеризованного индекса увеличивается, что может отрицательно сказаться на выполнении таких обычных операций, как соединения таблиц.
Идентификаторы GUID формируются без определенного порядка, в связи с чем строки вставляются в случайно выбранные позиции кластеризованного индекса. Это, в свою очередь, может вызвать фрагментацию кластеризованного индекса и отрицательно сказаться на эффективности ввода-вывода при запросах к базовой таблице.
В SQL Server 2005 и более поздних версиях имеется функция NEWSEQUENTIALID(), которая позволяет создавать идентификаторы GUID в последовательном порядке, что устраняет фрагментацию.
Ключи, содержащие идентификатор узла
При этом подходе используются ключи, сочетающие уникальное для узла сервера или клиента значение со значением, уникальным в топологии. Например, для синхронизации клиента и сервера можно использовать столбец автоприращений (уникальный в пределах узла) в сочетании со столбцом, в котором содержится хэш идентификатора, присваиваемого платформами Sync Framework каждому клиенту (это — значение ClientId, уникальное в пределах топологии). Затем создается составной первичный ключ, содержащий эти два столбца. В качестве альтернативы можно разработать систему, которая создавала бы значения для каждой вставляемой строки и предоставляла возможность включить в один столбец идентификатор строки и идентификатор клиента.
Естественные ключи
При этом подходе ни один из типов суррогатных ключей не используется, а вместо них для уникального определения записей применяется бизнес-ключ. Например, таблица, в которой хранятся сведения о заказчике, в качестве первичного ключа может использовать столбец номера социального страхования, а не столбец идентификаторов. Недостаток этого подхода состоит в том, что первичный ключ может стать слишком большим, если для уникального определения записи используется несколько столбцов. Более того, такой составной ключ необходимо распространить на другие таблицы, чтобы поддерживать связь по одному или нескольким внешним ключам. Это, в свою очередь, отрицательно повлияет на производительность операций соединения таблиц.
Оперативная вставка
Если ни одно из перечисленных выше решений не подходит, а на клиенте требуется лишь небольшое количество вставок, то приложение может производить вставку строк непосредственно на сервере. Во время следующей синхронизации эти строки будут загружены и вставлены на клиенте. Значения первичного ключа вырабатываются на сервере, поэтому конфликты первичных ключей не возникают.