Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

• Название: Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
• Автор: Хелен Борри
• Издательство: БХВ-Петербург
• Жанр: Программирование
• Год: 2006
• ISBN: 5-94157-609-9

Рассмотрены вопросы, необходимые разработчику для создания клиент-серверных приложений с использованием СУБД Firebird, явившейся развитием СУБД Borland Interbase 6. Содержится обзор концепций и моделей архитектуры клиент/сервер, а также практические рекомендации по работе с клиентскими библиотеками Firebird. Детально описаны особенности типов данных SQL, язык манипулирования данными (Data Manipulation Language, DML), а также синтаксис и операторы языка определения данных ( Data Definition Language, DDL). Большое внимание уделено описанию транзакций и приведены советы по их использованию при разработке приложений. Описано программирование на стороне клиента и сервера написание триггеров и хранимых процедур, создание и использование событий базы данных, обработка ошибок в коде на сервере и многое другое. Материал сопровождается многочисленными примерами, советами и практическими рекомендациями.

Для разработчиков баз данных

---

. ! .

Ссылочная целостность данных

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

Синтаксис ограничений формальной ссылочной целостности данных Firebird подробно обсуждается в главе 17.

Индексы и планы запросов

Если внешние ключи являются "кабелями", делающими базу данных реляционной, то индексы могут рассматриваться как поставщики "полосы частот". Хорошее индексирование повышает скорость; отсутствие индексов или плохие индексы замедляют поиск, соединение и сортировку.

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

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

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

Проектирование и создание индексов рассматривается в главе 18.

Просмотры

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

Просмотры и другие наследуемые таблицы обсуждаются в главе 24 и должны изучаться вместе с другими главами части V.

Хранимые процедуры и триггеры

Хранимые процедуры и триггеры являются модулями компилированных, выполняемых кодов, которые выполняются на сервере. Исходный код пишется на расширении языка SQL, называемом процедурным SQL, или PSQL.

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

Триггеры являются специализированным видом модулей PSQL, которые могут быть объявлены для выполнения в одном или более из шести состояний/фаз операции (до и после добавления, изменения и удаления) в процессе операций манипулирования данными (DML) таблицы, которая владеет этими триггерами. Группы триггеров могут быть объявлены для каждой фазы для выполнения в определенной последовательности. Начиная с релиза 1.5, поведение любой или всех операций DML могут быть объединены с условиями выполнения в один модуль триггера "до" или "после". Триггеры не принимают входных аргументов и не возвращают выходных наборов.

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

PSQL имеет механизмы обработки исключений и внешних событий. Любое количество сообщений об исключениях может быть определено в качестве объектов базы данных с использованием операторов CREATE EXCEPTION. Внешние события создаются внутри модуля PSQL, а приложения могут устанавливать структуры для их "прослушивания".

Подробное обсуждение написания и использования модулей PSQL, исключений и событий см. в части VII.

Соглашения по именованию объектов базы данных и ограничения

Должны соблюдаться ограничения в именовании объектов базы данных.

* Начинайте каждое имя с буквенного символа (A-Z или a-z).

* Ограничивайте имена объектов 31 символом. Некоторые объекты, например имена ограничений, могут иметь длину до 27 символов.

* Допустимые символы для имен файлов базы данных - как и для всех объектов метаданных в Firebird - включают знаки доллара ($), подчеркивания (_), цифры от 0 до 9, буквы от А до Z и от а до z.

* Обеспечьте требования уникальности в базе данных:

• во всех случаях имена объектов одного типа - например, таблиц - должны быть уникальными;

• имена столбцов в таблице должны быть уникальными в этой таблице. Все другие идентификаторы объектов должны быть уникальными в базе данных.

* Исключите использование зарезервированных слов, пробелов, диакритических знаков и любых символов ASCII с кодом больше 127:

• в диалекте 1 они вообще не могут быть использованы;

• в диалекте 3 вы можете ограничить "неправильные" идентификаторы, используя пару символов двойной кавычки. Подробности будут дальше.

Идентификаторы с разделителями SQL-92

В базах данных диалекта 3 Firebird поддерживает соглашение ANSI SQL об идентификаторах с разделителями. Для использования зарезервированных слов, диакритических знаков, чувствительных к регистру строк или пробелов в имени объекта заключите имя в двойные кавычки. Теперь оно становится идентификатором с разделителями. Идентификаторы с разделителями должны всегда быть представлены с двойными кавычками.

! ! !

ПРИМЕЧАНИЕ. В диалекте 1 зарезервированные слова, диакритические знаки и пробелы недопустимы в именах объектов; идентификаторы, чувствительные к регистру, не поддерживаются.

. ! .

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

SELECT "CodAR" FROM "MyTable"

отличается от

SELECT "CODAR" FROM "MYTABLE"

Заключать в кавычки или нет

Соглашение по двойным кавычкам для идентификаторов объектов было введено для совместимости со стандартами. Для тех, кто привык в прошлом в InterBase к нечувствительности к регистру, новая "возможность" будет в лучшем случае сбивать с толку, в худшем - раздражать.

Если вы определяете объекты в двойных кавычках, вы должны везде и всегда использовать их в двойных кавычках и обеспечивать соответствие регистра. Большинство опытных разработчиков Firebird рекомендует отказаться от них за исключением редких случаев, когда вам нужно использовать "неправильные" идентификаторы. Выбор за вами.

Исключение соответствия регистру

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

! ! !

СОВЕТ. Большинство графических инструментов базы данных Firebird предоставляет режим автоматического применения заключенных в кавычки идентификаторов. Один или два из этих инструментов фактически применяют идентификаторы в кавычках для всех объектов базы данных по умолчанию. Если у вас нет серьезных оснований использовать это, рекомендуется найти "отключающий переключатель" и отменить идентификаторы в кавычках.

. ! .

Соглашения по именованию файлов базы данных

Установленное соглашение по именованию файлов баз данных Firebird для любой платформы - использование трехсимвольного суффикса fdb для первичного файла, а для имен вторичных файлов f01, f02 и т.д. Это только соглашение - файлы Firebird могут иметь любое расширение или не иметь расширения вовсе.