Хранимые процедуры и триггеры
Хранимые процедуры и триггеры являются модулями компилированных, выполняемых кодов, которые выполняются на сервере. Исходный код пишется на расширении языка 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 могут иметь любое расширение или не иметь расширения вовсе.
По причине известных проблем с серверами XP, использующими SystemRestore для файлов с расширением gdb, разработчикам рекомендуется заменить традиционный суффикс файлов InterBase при миграции баз данных в Firebird.
Имя базы данных безопасности- security.fdb в релизе 1.5 и выше, isc4.gdb в релизе 1.0.x- не должно изменяться. К сожалению, у Firebird 1.0.x нет средств изменения требуемого суффикса gdb.
Скрипты схемы
В Firebird, как и во всех других системах управления базами данных SQL, вы создаете вашу базу данных и ее объекты (метаданные или схема базы данных), используя операторы из специализированного подмножества операторов SQL, называемого языком определения данных (Data Definition Language, DDL). Пакет операторов DDL в текстовом файле называется скриптом. Скрипт или множество скриптов могут быть обработаны программой isql непосредственно из командной строки или при помощи инструмента, предоставляющего дружественный интерфейс.
Список таких инструментов см. в приложении 5.
Скрипты Firebird
Скрипт для создания и изменения объектов базы данных иногда называют файлом определения данных или скриптом DDL. Скрипт DDL может содержать определенного рода операторы isql, а также некоторые из команд SET <параметр>. COMMIT также является допустимым оператором в скрипте.
! ! !
ПРИМЕЧАНИЕ. Утилита isql (интерактивный SQL) является программой командной строки, доступной на всех платформах; входит в состав комплекта поставки Firebird. Во всех случаях, кроме встроенного сервера для Windows, isql инсталлируется в каталог /bin корневого каталога Firebird. Полные инструкции см. в главе 37.
. ! .
Другие скрипты могут быть написаны для добавления основных, или "управляющих", данных в таблицы, изменения столбцов, преобразования данных и выполнения других задач, включающих манипулирование данными. Такие скрипты называются скриптами DML (для языка манипулирования данными, Data Manipulation Language).
Команды DDL и DML могут одновременно присутствовать в скриптах. Однако для устранения проблем с целостностью данных строго рекомендуется размещать операторы DDL и DML в отдельных скриптах. Обработка скриптов позволяет "изменять" скрипты, связывая один файл скрипта с другим с помощью оператора isql INPUT <спецификация_файла>.
Операторы скрипта выполняются в строгом порядке. Использование команды SET AUTODDL позволяет управлять подтверждением операторов или блоков операторов. Эта команда также позволяет откладывать подтверждение содержимого скрипта, пока не будет выполнен весь скрипт.
Зачем использовать скрипты?
Очень хорошей практикой является использование скриптов DDL для создания вашей базы данных и ее объектов. Перечислим несколько причин для этого.
* Самодокументирование. Скрипт является текстовым файлом, просто обрабатываемым любым текстовым редактором. Скрипты могут (и должны) включать подробные тексты комментариев. Изменения метаданных могут быть отмечены с указанием даты вручную.
* Управление разработкой базы данных. Представление всех описаний базы данных в скриптах позволяет создание схемы тесно интегрировать с циклами проектирования задач и пересмотра кода.
* Повторяемое и отслеживаемое создание метаданных. Полностью восстанавливаемая схема является требованием гарантированного восстановления системы после сбоев во многих организациях.
* Аккуратное конструирование и реконструирование метаданных базы данных. Опытные программисты Firebird часто создают набор скриптов DDL, разработанных для выполнения и подтверждения в нужном порядке. Это упрощает отладку и гарантирует, что объекты будут существовать, когда позже зависимые объекты будут на них ссылаться.