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

* поля, имеющие тип DATE, рассматриваются клиентами 5.x как тип TIMESTAMP, т. к. в 4.x и 5.x тип "дата+время" назывался DATE.

Клиенты, применяющие для доступа к базе данных BDE версии ниже 5.3, не могут использовать объекты, имеющие новые типы данных, появившихся в 3-м диалекте InterBase 6.x.

Подводя итог разделу о совместимости клиентов и серверов, необходимо добавить, что, несмотря на возможность использовать "старых" клиентов, лучше всего использовать клиентов той же версии, которую имеют и серверы. Причем желательно, чтобы это соответствие было точным - вплоть до номеров билдов. То есть если вы используете в качестве сервера какой-нибудь клон InterBase. например Fuebnd 1 0, то желательно использовать и клиента именно от этой версии, а не от InterBase 6.0.1, например.

Перевод базы данных InterBase 6.x на 3-й диалект

Итак, мы подходим к рассмотрению вопроса о переводе баз данных InterBase 6 1-го диалекта на диалект 3, использующий все возможности версии 6.x. Начнем рассматривать этот перевод с предположения, что в качестве исходного материала мы имеем базу данных InterBase 6.x диалекта 1 и клиентские приложения, использующие синтаксис 1-го диалекта.

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

Итак, что же мешает нам перевести нашу базу данных в 3-й диалект? Существует 4 основных препятствия, которые надо преодолеть, чтобы успешно перейти на 3-й диалект, - это двойные кавычки, ключевые слова, новые типы данных DATE и большие целые числа.

Двойные кавычки

Если в версиях InterBase 4.x и 5.x и диалекте 1 версии 6.x строковые константы позволялось описывать как с помощью как одинарных, так и двойных кавычек, то в 3-м диалекте двойные кавычки применяются только для обозначения идентификаторов, а одинарные - для строковых констант. Чтобы базу можно было перевести из 1-го диалекта в 3-й, необходимо заменить все двойные кавычки, ограничивающие строковые константы, на одинарные. Двойные кавычки могут находиться в триггерах, хранимых процедурах, представлениях, доменах, ограничениях и в значениях столбцов по умолчанию.

Ключевые слова

Новые ключевые слова могли быть использованы в базе данных, созданной в InterBase 4.x или 5.x, в качестве идентификаторов каких-либо объектов. Для перехода к диалекту 3 необходимо переименовать эти объекты, например YEAR -> YEAR 1 или YEAR->"year" (в 3-м диалекте ключевые слова могут быть идентификаторами, если они заключены в двойные кавычки) При смене диалекта базы данных лучше не использовать кавычки для разрешения конфликтов с ключевыми словами: разработчику надо привыкнуть к такому стилю работы и запомнить, что "Year", "YEAR" и "year" - разные идентификаторы.

Типы данных для работы с датой и временем

В версиях 4.x и 5.x и 1-м диалекте 6.x присутствует только один тип данных - DATE, который позволяет хранить информацию о дате и времени суток. В 3-м диалекте существует 3 типа для работы с датой и временем - это тип TMESTAMP, хранящий информацию о дате и времени (т. е он аналогичен типу DATE в 1-м диалекте и в 5.x), тип DATE, хранящий информацию только о дате, и тип TIME, хранящий информацию только о времени. Довольно запутанно, не так ли? Функции "старого доброго" DATE теперь берет на себя TIMESTAMP, a DATE, изменив свое назначение, означает теперь только дату.

Как же происходит замена типов данных? Объявления столбцов типа DATE автоматически меняют свой тип на TIMESTAMP уже при переходе на диалект 1 InterBase 6x, а вот с переменными типа DATE, использующимися (может быть) в триггерах и процедурах, ситуация сложнее. Они не меняют свой тип автоматически, и необходимо будет сменить их тип ("старый" DATE) на TIMESTAMP перед сменой диалекта 1 на 3.

Большие целые типы

В 3-м диалекте целые числа, имеющие тип NUMERIC или DECIMAL и разрядность больше девяти, хранятся в виде INT64, а менее девяти - в виде DOUBLE PRECISION. В 1-м диалекте и старых версиях все большие целые числа хранятся как DOUBLE PRECISION.

Обратите внимание, что INT64 - это обозначение механизма хранения больших целых чисел, а не какой-то конкретный тип

При переходе с 1-го диалекта на 3-й НИЧЕГО не изменится в хранении больших целых чисел, созданных ДО перехода на 3-й диалект, - они по- прежнему будут иметь тип DOUBLE PRECISION. Чтобы воспользоваться преимуществами хранения данных в INT64 (подробности см. в главе "Типы данных" (ч 1)). можно перенести данные в столбец с типом INT64 Для переноса нужно создать новый столбец нужной разрядности (например, NUMERIC(15,2)), который будет хранить свои значения в виде INT64, и перенести туда значения из старого столбца, затем старый столбец-источник удалить, а новый (со значениями в INT64) переименовать как старый. Переименование легко осуществить, воспользовавшись командой ALTER COLUMN, которая может сменить имя, тип и позицию столбца.

Вот такие препятствия ждут нас на пути к 3-му диалекту. Теперь от обзора перейдем к пошаговому алгоритму перевода базы данных от 1-го диалекта к 3-му. Мы будем рассматривать вариант, названный в [3, глава "Migration Guide"] способом "In-place migration", - когда база данных переводится на 3-й диалект без полного пересоздания базы данных и перекачки всех данных из старой базы данных в новую.

Пошаговые инструкции для перехода на 3-й диалект

Исходные данные: предположим, что мы переводим базу данных, состоящую из одного файла, - base2migrate.gdb. База данных - источник имеет 1 диалект. Резервная копия базы данных-источника сделана.

Итак, начнем.

* Необходимо получить метаданные, описывающие базу данных-источник в 1-м диалекте. Для этого выполняем команду вида isql base2migrate.gdb -x -user SYSDBA -password masterkey -о baseSource.ddl, которая извлечет метаданные и поместит их в файл baseSource.ddl. Эта команда выполнится успешно, если база данных-источник находится в том же каталоге, в котором находится и isql, в другом случае придется указать полный путь к базе данных.

* Необходимо создать пустой файл с именем вроде makelt.sql, в который будут заноситься команды изменения метаданных базы данных, которые получим на основе анализа файла baseSource.ddl на предмет несоответствия содержащихся там метаданных требованиям диалекта 3. Команды изменения из файла makelt.sql подготовят базу данных-источник к переходу. Дальнейшие шаги до перехода будут посвящены наполнению файла.

* Отыскиваем в файле baseSource.ddl все двойные кавычки и заменяем их на одинарные. Затем копируем все измененные выражения в файл makelt.sql. Например, если строка, ограниченная двойными кавычками, находится внутри триггера, то надо скопировать весь триггер с измененной строкой (и не за- о\дые предложение set term перед триггером!). Заметьте, что простым поиском/заменой кавычек здесь не обойтись, ведь двойные и одинарные кавычки могут быть и в середине, и в конце, и в начале строковых констант. Для замены следует воспользоваться следующими правилами, составленными на основе таблицы 2.1 в InterBase б Mignation Guide [3]:

Табл 4.8. Правила перевода строк с двойными кавычками

Двойные кавычки внутри строки
Строка без кавычек как она есть	In "peg" mode
Строка, заключенная в двойные кавычки (допускается правилами IВ5.х и 1-го диалекта)	"In ""peg"" mode"
Строка, заключенная в одинарные кавычки согласно требованиям правил диалекта 3	'In "peg" mode'
Одинарные кавычки внутри строки
Строка без кавычек	O'Reilly
Строка, заключенная в двойные кавычки (допускается правилами IВ5.х и 1-го диалекта)	"O'Reilly"
Строка, заключенная в одинарные кавычки, согласно требованиям правил диалекта 3	'O"Reilly'