Шрифт:
Главное преимущество использования ограничений состоит в возможности реализовать проверку данных, а значит, и часть бизнес-логики приложения на уровне базы данных, т. е. централизовать и упростить ее, а значит, сделать разработку приложений баз данных проще и надежнее.
Часто начинающие разработчики пренебрегают использованием ограничений базы данных, считая, что они стесняют возможность творчества. Однако на самом деле такое мнение происходит от недостаточного знания теории и практики проектирования баз данных.
В то же время наиболее опытные разработчики позволяют себе отказаться от использования некоторых видов ограничений, за счет чего их приложения выигрывают в быстродействии. Опыт высококвалифицированных разработчиков позволяет им очень хорошо понимать работу сервера и точно предсказывать его поведение в сложных случаях, поэтому начинающим программистам InterBase лучше не апеллировать к подобным действиям опытных коллег.
В рамках данной книги мы не рассматриваем проектирование баз данных, поэтому для получения дополнительной информации по этому вопросу следует обратиться к списку литературы в конце книги. Здесь же мы лишь проведем обзор всех видов ограничений в базе данных InterBase и рассмотрим примеры их применения.
Виды ограничений в базе данных
Существуют следующие виды ограничений в базе данных InterBase:
* первичный ключ - PRIMARY KEY;
* уникальный ключ - UNIQUE KEY;
* внешний ключ - FOREIGN KEY
– может включать автоматические триггеры ON UPDATE и ON DELETE;
* проверки - CHECK.
В предыдущих главах уже упоминались некоторые из этих ограничений, что было необходимо для логичного изложения материала, но теперь мы рассмотрим их синтаксис, применение и реализацию более обстоятельно.
Ограничения базы данных бывают двух типов - на основе одного поля и на основе нескольких полей таблицы. Синтаксис обоих видов ограничений приведен ниже.
<col_constraint> = [CONSTRAINT constraint] <constraint_def>
[ <col_constramt> . . . ]
<constraint_def> = {UNIQUE | PRIMARY KEY
| CHECK ( <search_condition>)
| REFERENCES other_table [( other_col [, other_col ...])]
[ON DELETE (NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
[ON UPDATE (NO ACTION CASCADEjSET DEFAULTjSET NULL}]
}
Для ограничений на основе нескольких полей синтаксис следующий:
<tconstraint> = [CONSTRAINT constraint] <tconstraint_def>
[< tconstraint> ...]
<tconstraint_def> = {{PRIMARY KEY | UNIQUE} ( col [, col ...] )
FOREIGN KEY ( col [, col ...] ) REFERENCES other_table [ ( other_col [ , other_col ...] ) ]
[ON DELETE (NO ACTION|CASCADE SET DEFAULT|SET NULL}] [ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
| CHECK ( <search_condition>)}
Разница в синтаксисе между ограничениями на основе одного поля и на основе нескольких очевидна - в последних молено указать несколько полей, которые входя i в ограничение. В сд\чае ограничения на основе одного поля все описанные опции относятся только к текущему полю.
Конечно, у этих двух типов ограничений отличается способ их применения: ограничения на основе одного поля просто дописываются к определению нужного поля, а ограничения на основе нескольких полей указываются через запятую в общем определении таблицы. Подробные примеры приведены в следующих разделах этой главы.
Пример типичного ограничения
Фактически ограничения на основе одного поля являются частным сл\чаем ограничений на основе нескольких полей.
Пример создания ограничения первичного ключа с использованием этих двух различных подходов приведен ниже. Давайте создадим таблицу, содержащую только одно поле и наложим на нее ограничение первичного ключа.
Первичный ключ с использованием синтаксиса ограничения на основе одного поля.
CREATE TABLE testl(
ID_PK INTEGER CONSTRAINT pktest NOT NULL PRIMARY KEY) ;
В этом примере создается первичный ключ с именем pktest на поле ID_PK. Получаем весьма компактное описание в одну строчку.
Для той же самой цели можно воспользоваться синтаксисом ограничений на основе нескольких полей:
CREATE TABLE test2(
ID_PK INTEGER NOT NULL,
CONSTRAINT pktst PRIMARY KEY (ID_PK));
Создание ограничений
Давайте рассмотрим создание ограничений подробнее. Первой в описании общего синтаксиса ограничений идет опция [CONSTRAINT constraint]. Как видите, эта опция взята в квадратные скобки и, значит, необязательна.