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

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

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

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

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

Резюме

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

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

Глава 6

Формирование более качественных запросов; расширенные запросы

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

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

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