А Ковязин - Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil

• Название: Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
• Автор: А Ковязин
• Жанр: Программирование

Добро пожаловать в форум...

Тема: "Мир Interbase.." или "FireBird.." Что выбрать

Здравствуйте, Господа!

Начинаю потихоньку знакомиться с InterBase и решил приобрести книжку (поскольку с монитора читать довольно тяжело). Почитав отзывы, понял, что выбирать придется между «Мир InterBase» (Ковязин, Востриков) и «FireBird. Руководство разработчика баз данных) (Х.Борри). К сожалению, денег на обе не хватит.

В связи с этим вопросы:

·Какая из этих книг доступнее для новичка, только начинающего изучать СУБД и проектирование БД

·В какой степени эти книги, так сказать, взаимозаменяемы. Т.е. насколько знания, полученные из книги про InterBase(например) применимы для работы с FireBird и наоборот.

Заранее всем спасибо за ответы.

С уважением, Londinium

---------

Гаджимурадов Рустам

1. Если ты совсем новичек, то бери первую - в ней доступнее.

2. Если ты новичек только в ИБ, то лучше вторую.

3. Вторую книжку желательно иметь под рукой по-любому - независимо от того, есть ли первая.

4. Важно - во второй нет нихрена (кажется) про библиотеки доступа (IBX, FIBPlus).

5. Знания про InterBase, полученные из первой книги, применимы к FireBird практически в полном объеме.

...

---

Мы рассмотрели несколько способов улучшить производительность индексов. С помощью команд ALTER INDEX и DROP/CREATE INDEX можно перестраивать любые индексы, за исключением системных, создаваемых автоматически индексов, служащих для поддержания ссылочной целостности. Чтобы перестроить эти индексы, необходимо воспользоваться командами изменения и создания таблиц - ALTER TABLE и CREATE TABLE, так как эти индексы являются неотъемлемой частью табличных ключей.

Ограничения базы данных

Эта глава посвящена ограничениям базы данных InterBase. Ограничения базы данных, - это правила, которые определяют взаимосвязи между таблицами и могут проверять и изменять данные в базе данных Реализованы эти правила в виде особых объектов базы данных.

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

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

В то же время наиболее опытные разработчики позволяют себе отказаться от использования некоторых видов ограничений, за счет чего их приложения выигрывают в быстродействии. Опыт высококвалифицированных разработчиков позволяет им очень хорошо понимать работу сервера и точно предсказывать его поведение в сложных случаях, поэтому начинающим программистам 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]. Как видите, эта опция взята в квадратные скобки и, значит, необязательна.

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

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

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

Первичный и уникальный ключи

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

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

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

Синтаксис создания первичного и уникального ключа на основе единственного поля следующий:

<pkukconstraint> = [CONSTRAINT constraint] {PRIMARY KEY |

UNIQUE}

Примеры первичных и уникальных ключей:

CREATE TABLE pkuk(

pk NUMERIC(15,0) NOT NULL PRIMARY KEY, /*первичный ключ*/

ukl VARCHAR(SO) NOT NULL UNIQUE,/*уникальный ключ */

uk2 INTEGER NOT NULL UNIQUE /* еще уникальный ключ */);

Синтаксис создания первичного и уникального ключей на основе нескольких полей:

<pkuktconstraint> = [CONSTRAINT constraint] {PRIMARY KEY |

UNIQUE) ( col [, col ...] )

Такой синтаксис позволяет создавать ключи на основе комбинации полей. Вот примеры создания первичных и уникальных ключей из нескольких полей:

CREATE TABLE pkuk2(

Number1 INTEGER NOT NULL,

Namel VARCHAR(SO) NOT NULL,

Kol INTEGER NOT NULL,

Stoim NUMERIC(15,4) NOT NULL,

CONSTRAINT pkt PRIMARY KEY (Numberl, Namel), /*первичный ключ pkt на

основе двух полей*/

CONSTRAINT uktl UNIQUE (kol, Stoim) ); /*уникальный ключ uktl на основе

двух полей*/

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

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

ALTER TABLE tablename

ADD [CONSTRAINT constraint] {PRIMARY KEY | UNIQUE) ( col [, col ...] )

Давайте рассмотрим пример создания первичного и уникального ключа с помощью ALTER TABLE. Сначала создаем таблицу:

CREATE TABLE pkalter(

ID1 INTEGER NOT NULL,

ID2 INTEGER NOT NULL,

UID VARCHAR(24));

Затем добавляем ключи. Сначала первичный:

ALTER TABLE pkalter

ADD CONSTRAINT pkall PRIMARY KEY (idl, id2);