Перенос приложений MIDAS с одной СУБД на другую

Перенос приложений MIDAS с одной СУБД на другую

Александр Капустин

Введение

В данной статье рассматриваются проблемы, связанные с миграцией приложения MIDAS с одной СУБД на другую. Рассмотрим это на примере переноса приложения, описанного в статье Романа Игнатьева "MIDAS: практика применения". Приложение написано под Interbase 5.6 и использует компоненты IBX на сервере приложений для доступа к СУБД. Перепишем его таким образом, чтобы приложение смогло работать под управлением MSSQL Server 7.0 и MSSQL Server 2000 (при помощи небольших переделок скрипта можно добиться работы приложения под Sybase ASE 12.0). Следует также заметить, что переделке подвергнутся только скрипт СУБД и сервер приложений. Клиентская часть остается нетронутой, т.к. при использовании многозвенной архитектуры она абсолютно изолирована от деталей реализации серверной части.

Некоторые замечания к содержанию статьи.

Предполагается, что читателю уже знакомы (хотя бы в начальной стадии) синтаксис SQL (в приложении либо к Interbase, либо к MSSQL, а также общие принципы работы с БД из Delphi (в статье используются IBX&ADO, но это не единственно возможное решение).

Процесс переноса происходит уже после того, как приложение отлажено и стабильно работает (т.к. параллельная разработка для нескольких СУБД – немного другой случай, и его мы рассматривать не будем).

Хотелось бы сказать несколько слов о том, зачем это вообще нужно, что мы приобретаем, и что теряем (немного теории).

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

Но при этом мы перестаем использовать на 100% возможности какой-либо отдельной СУБД. Следует различать два случая. Первый случай, когда поддерживается совместимость со старыми версиями этой же СУБД (например, поддерживается линейка MSSQL 6.5 – MSSQL2000). В этом случае мы ограничены возможностями самой слабой версии, и не можем использовать нововведения. Второй случай, гораздо более тяжелый и вместе с тем интересный для рассмотрения, когда планируется совместимость между различными СУБД, например между MSSQL и Interbase. Должен сразу оговориться, что этот случай встречается гораздо реже, но если вы при проектировании приложения не будете учитывать эту возможность, то переход вызовет гораздо больше сложностей.

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

Модификация структуры БД

К сожалению, перенос структуры БД "один-в-один" между различными СУБД практически невозможен. Здесь приведено описание некоторых проблем, с которыми придется столкнуться при переносе, а также возможные пути их решения. Лучше всего, если бы эти вещи были учтены изначально при проектировании исходного приложения, т.к. в этом случае объем работ при переносе приложения сокращается.

Добавление записей в таблицу

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