PSQL имеет механизмы обработки исключений и внешних событий. Любое количество сообщений об исключениях может быть определено в качестве объектов базы данных с использованием операторов CREATE EXCEPTION. Внешние события создаются внутри модуля PSQL, а приложения могут устанавливать структуры для их "прослушивания".
Подробное обсуждение написания и использования модулей PSQL, исключений и событий см. в части VII.
Соглашения по именованию объектов базы данных и ограничения
Должны соблюдаться ограничения в именовании объектов базы данных.
* Начинайте каждое имя с буквенного символа (A-Z или a-z).
* Ограничивайте имена объектов 31 символом. Некоторые объекты, например имена ограничений, могут иметь длину до 27 символов.
* Допустимые символы для имен файлов базы данных - как и для всех объектов метаданных в Firebird - включают знаки доллара ($), подчеркивания (_), цифры от 0 до 9, буквы от А до Z и от а до z.
* Обеспечьте требования уникальности в базе данных:
• во всех случаях имена объектов одного типа - например, таблиц - должны быть уникальными;
• имена столбцов в таблице должны быть уникальными в этой таблице. Все другие идентификаторы объектов должны быть уникальными в базе данных.
* Исключите использование зарезервированных слов, пробелов, диакритических знаков и любых символов ASCII с кодом больше 127:
• в диалекте 1 они вообще не могут быть использованы;
• в диалекте 3 вы можете ограничить "неправильные" идентификаторы, используя пару символов двойной кавычки. Подробности будут дальше.
В базах данных диалекта 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, разработанных для выполнения и подтверждения в нужном порядке. Это упрощает отладку и гарантирует, что объекты будут существовать, когда позже зависимые объекты будут на них ссылаться.