го возвращаться и заполнять идентификационные значения вместо значений тех строк, которые, возможно, бьши удалены. Если же в подобных случаях требуется заполнить пустующие поля, то необходимо использовать опцию SET IDENTITY INSERT ON, которая позволяет остановить процесс выработки идентификационных значений для операторов вставки, выполняемых в текущем соединении (да, здесь нет ошибки; после задания значения параметра ON выработка и вставка идентификационных значений прекращается; иными словами, параметр ON указывает, что пользователь желает получить возможность вставлять самостоятельно вырабатываемые значения, для чего необходимо отменить использование средств автоматической вставки значений).

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

Разработчики, знакомые с СУБД Access, могут обнаружить, что столбцы IDENTITY во многом аналогичны столбцам AutoNumber. Основное различие между ними состоит в том, что СУБД SQL Server обеспечивает немного больший контроль над значениями этих столбцов, чем СУБД Access.

Ключевое СЛОВО not for replication

На данный момент задача достаточно подробного описания опции NOT FOR REPLICATION является довольно сложной, поэтому рассмотрим лишь ее основные возможности; более подробное описание приведено в главе 20.

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

Параметр NOT FOR REPLICATION определяет, следует ли присваивать столбцу, публикуемому (с помощью репликации) в другой базе данных, новое идентификационное значение (вырабатываемое в этой новой базе данных) или сохранять существующее значение. Дополнительные сведения по этой теме будут приведены ниже.

Ключевое слово rowguidcol

Опция ROWGUIDCOL также связана с репликацией и применительно к столбцу идентификации имеет в основном такое же назначение. Как уже было отмечено, применение столбца идентификации позволяет предусмотреть удобный способ выработки значений, уникальных для каждой строки, которые поэтому могут использоваться для однозначного обозначения этой строки. Но решение, основанное на применении столбца идентификации, способствует возникновению ошибок, если оно реализовано в такой среде, в которой применяется репликация, или в другой распределенной среде.

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

С годами сложилось такое общепринятое решение этой задачи, которое предусматривает использование отдельных начальных значений для каждой базы данных, применяемой в качестве источника или получателя реплицированных данных. Например, может быть предусмотрено, чтобы в базе данных А отсчет идентификационных значений начинался с 1, в базе данных В - с 10001, а в базе данных С - с 20001. Таким образом, появляется возможность без опасений публиковать данные всех этих трех баз данных в какой-то четвертой базе данных. Но это не может продолжаться до бесконечности. Как только, допустим, база данных А вырастет в объеме и станет включать больше 9999 строк, начнутся большие неприятности.

На это можно было бы возразить, указав, что решением может служить разделение начальных значений не на 10000, а на 100000 или даже на 500000. Но если обмен данными с таблицей происходит достаточно активно, то указанное решение лишь отдаляет неизбежный конец. Именно в связи с этим применяется решение, основанное на ключевом слове ROWGUIDCOL.

Опция ROWGUIDCOL позволяет по-другому подойти к решению задачи идентификации. Безусловно, по своему назначению эта опция также является средством заполнения столбца идентификации, который обычно используется для однозначного определения каждой строки в таблице. А ее отличительной особенностью является гораздо большая длина последовательности значений в столбце ROWGUIDCOL, в пределах которой система гарантирует полную уникальность вырабатываемых значений. В СУБД SQL Server при формировании значений ROWGUIDCOL применяется не наращивание числовых значений, а выработка так называемых глобально уникальных идентификаторов, или GUID (Globally Unique Identifier). Можно условно считать, что значения столбцов идентификации обычно являются уникальными во времени (если параметры, применяемые при выработке этих значений, остаются неизменными), но они не уникальны в пространстве. Поэтому, если эксплуатируются две копии таблиц в разных базах данных, строкам обеих этих таблиц присваиваются повторяющиеся значения в столбцах идентификации. На первых порах в процессе эксплуатации

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

В настоящее время значения GUID используются в программном обеспечении практически повсеместно. Например, огромное количество таких значений обнаруживается при проверке реестра операционной системы Windows. Любое значение GUID является 128-битовым, поэтому если оно рассматривается как двоичное значение, выраженное с помощью одного из числовых типов, то требует для своего представления в десятичной форме не меньиле 38 знаков. Согласно теоретическим расчетам, если бы новое значение GUID вырабатывалось через каждую секунду, то до появления дубликата числа с такой значностью прошли бы миллионы лет.

Значения GUID вырабатываются на основе использования некоторого сочетания информационных компонентов, причем эти компоненты выбраны таким образом, чтобы каждый из них был уникальным либо в пространстве, либо во времени. А после использования всех этих компонентов в их сочетании формируется значение, для которого с точки зрения статиетики гарантируетея уникальность в пространстве и во времени.

Обычно в программировании для выработки значений GUID используется один из вызовов API-интерфейса Windows, а в языке SQL предусмотрена возможность не только задать для столбца опцию ROWGUIDCOL, но и применить специальную функцию, возвращающую значение GUID; эта функция называется NEWID () и может быть вызвана в любое время.

Ключевое слово collate

Опция COLLATE действует главным образом по такому же принципу, как и в команде CREATE DATABASE; основное различие состоит в том, что в данном случае область действия становится более узкой (поскольку она определяется на уровне столбца, а не на уровне базы данных).

Ключевое слово null/not null

Опция NULL и (или) NOT NULL имеет довольно простое назначение - с ее помощью можно указать, допускает ли столбец, к которому она относится, ввод NULL-значений, или нет. По умолчанию сразу после инсталляции СУБД SQL Server для любого столбца задается значение опции NOT NULL, если только во время инсталляции не будет предусмотрена возможность применения неопределенных значений, или NULL-значений (nullability). Тем не менее имеется очень большое количество параметров настройки конфигурации сервера, которые могут повлиять на эту опцию и изменить способ ее применения. Например, значение этой опции может измениться после задания любого значения с помощью хранимой процедуры sp dbcmpt level или установки опций совместимости со стандартом ANSI.

Автор настоятельно рекомендует явно задавать опцию NULL или NOT NULL для каждого столбца при создании любой таблицы. Это позволяет предотвратить возможную путаницу. Как уже бьшо сказано, в СУБД SQL Server предусмотрено большое количество различных параметров настройки конфигурации, которые могут повлиять на то, какое значение будет использоваться в системе по умолчанию для определения