Опции и спецификации определения условий завершения

В СУБД SQL Sender предусмотрено несколько опций, которые могут быть заданы с помощью оператора ALTER DATABASE. К ним относятся, в частности, опции определения значений по умолчанию, касающихся конкретной базы данных, для большинства доступных опций SET (таких как ANSI PADDING и ARITHABORT; подобной возможностью модификации базы данных удобно воспользоваться, если в приложении треб}тотся индексированные или секционированные представления), опции состояния (например, определяющие эксплуатацию базы данньгх в однопользовательском режиме или режиме только чтения) и опции восстановления. Под воздействием различных опций SET функционирование базы данных изменяется, и в настоящей книге об этом часто идет речь при обсуждении соответствующих тем. А указанные новые функциональные возможности оператора модификации базы данньгх просто предоставляют пользователю дополнительный способ корректировки значений параметров настройки, применяемых по умолчанию для любой конкретной базы данных.

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

Оператор alter table

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

Рассмотрим прежде всего основную синтаксическую структуру оператора модификации таблицы:

ALTER TABLE table name

{[ALTER COLUMN <column name>

{ [<schema of new data type>].<new data type> [(precision [, scale])] max <xml sctiema collection>

[COLLATE <collation name>]

[NULL I NOT NULL]

I [{ADD I DROP} ROWGUIDCOL] PERSISTED}]

I ADD

<column name> <data type> [[DEFAULT <constant expression>]

I[IDENTITY [(<seed>, <increment>) [NOT FOR REPLICATION]]]] [ROWGUIDCOL]

[COLLATE <collation name>]

[NULL I NOT NULL] [<column constraints>]

[<column name> AS <computed column expression>]

[(<referenced column>[ ,...n])]

[CONSTRAINT <constraint name>] {[{PRIMARY KEY UNIQUE}

[CLUSTERED NONCLUSTERED] (<column name>[ ,...n ])}

:WITH FILLFACTOR = <fillfactor>]

[ON {<filegroup> DEFAULT}]

I FOREIGN KEY

[(<column name>[ ,...n])] REFERENCES <referenced table> [ON DELETE {CASCADE NO ACTION [ON UPDATE {CASCADE NO ACTION [NOT FOR REPLICATION] I DEFAULT <constant expression>

[FOR <column name>] I CHECK [NOT FOR REPLICATION] (< searcli condi t ions >) [,...n] [ , . . .n]

I [WITH CHECK I WITH NOCHECK] I { ENABLE I DISABLE } TRIGGER

{ ALL I <trigger name> [ ,...n ] }

I DROP

{[CONSTRAINT] <constraint name>

I COLUMN <column name>}[ , ...n] I{CHECK NOCHECK} CONSTRAINT

{all <constraint name>[ ,...n]} I {ENABLE I DISABLE} TRIGGER

{all I<trigger name>[ , ...n]} I SWITCH [ PARTITION <source partition number expression> ]

TO [ scliema name. ] target table

[ PARTITION <target partition number expression> ]

Очевидно, что оператор модификации таблицы не менее сложен, чем оператор создания таблицы.

Итак, начнем с примера использования оператора модификации таблицы и для этого снова вернемся к таблице Customers базы данных Accounting: EXEC sp lielp Customers

В целях уменьшения объема представленной здесь информации полученные результаты отредактированы и показана лишь та часть, которая нас интересует, но фактически объем выводимой информации гораздо больше (табл. 4.5).

Таблица 4.5. Характеристики столбцов таблицы Customers

Предположим, что возникла необходимость дополнительно обеспечить хранение в таблице Customers федеральных идентификационных номеров заказчиков. Для решения этой задачи достаточно ввести еще один столбец, а такая операция является довольно простой. Синтаксическая структура необходимого для этого оператора во многом напоминает структуру соответствующего оператора CREATE TABLE, не считая тех очевидных изменений, которые зависят от типа самого оператора:

ALTER TABLE Customers ADD

FedlDNo varchar(9) NULL

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

ALTER TABLE Customers ADD

Contact varchar(25) NULL,

LastRaiseDate datetime NOT NULL

DEFAULT 2005-11-07

Обратите внимание на то, что в последнем случае предусмотрено применение ключевого слова DEFAULT. Фактически использование этого ключевого слова еще подробно не рассматривалось (речь о нем пойдет в следующей главе), но автор в этом примере хотел бы отметить особый случай.

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

Анализ структуры таблицы Customers с помощью хранимой процедуры sp help показывает, что добавление новых столбцов произошло успешно. Но следует отметить, что добавленные столбцы оказались в конце списка столбцов. В СУБД SQL Server не предусмотрена возможность добавлять столбцы в любом конкретном месте. А если требуется поместить какой-то столбец в середину, то следует создать полностью новую таблицу (с другим именем), скопировать данные в новую таблицу, уничтожить существующую таблицу с помощью оператора DROP, а затем переименовать новую таблицу, назвав ее так же, как старую.

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