База знаний студента. Реферат, курсовая, контрольная, диплом на заказ

курсовые,контрольные,дипломы,рефераты

Перенос приложений 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 новой записи. Это позволяет легко добавлять записи в подчиненную таблицу, не производя никаких дополнительных манипуляций. В дальнейшем вы можете возложить на эту процедуру, например, генерацию идентификаторов в заданном диапазоне, или обеспечить сквозную нумерацию. Для хранения идентификаторов проще всего иметь отдельную таблицу примерно следующего вида:

create table Seeds (

 TableName varchar(30),  --имя таблицы

 ID int,         --ID последней вставленной записи в данную таблицу

 LowOffset int      --нижняя граница диапазона

)

go

При добавлении пользовательских таблиц необходимо не забывать вставлять в эту таблицу соответствующие записи. Ниже приведен пример SQL-запроса, делающего это:

insert into Seeds(TableName, ID, LowOffset, HiOffset)

 values('MyCoolTable', 0, 0, 1000000)

go

Текст процедуры в простейшем случае будет выглядеть так:

create procedure CLIENT_ID

 @TableName varchar(30),

 @ID int output

as

 update Seeds

  set ID = ID + 1,

    @ID = ID + LowOffset

  where TableName = @TableName

go

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

Контроль целостности данных

При проектировании базы необходимо учесть следующие ограничения:

Каскадное изменение по foreign key появилось только в MSSQL2000. Так что если задаться целью сохранить совместимость с предыдущими версиями (а также с Sybase), каскадные изменения необходимо производить при помощи хранимых процедур (почему не использовать триггеры, сказано ниже).

Триггеры, отрабатывающие не после проверки всех ограничений целостности, а вместо действия, на которое их вызвали, также появились только в MSSQL2000. В более ранних версиях они просто не смогли бы отработать каскадное изменение при наличии foreign key. Также при написании триггеров следует учесть особенности реализации для каждой СУБД. Так, например, в Interbase триггер отрабатывает на каждую запись, а в MSSQL – на изменение, вставку или удаление записи. Как вариант, можно отказаться от поддержки целостности, основанной на foreign key, и реализовать ее полностью на триггерах.

Перенос скрипта

Здесь приведены основные трудности, с которыми можно столкнуться при переносе скрипта Interbase на MSSQL (должен еще раз повториться, что статья не претендует на полный и детальный разбор отличий между этими СУБД, да такой анализ и не может быть полностью корректным).

Соответствие встроенных типов

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

IB MSSQL Комментарий
char char -в MSSQL – не более 8000, в IB - не более 32767 char
varchar varchar -в MSSQL - не более 8000, в IB - не более 32767 char
blob text, image
date datetime, smalldatetime (последний обрезает время до минут)
money, smallmoney - в IB нет аналогов
bit - в IB нет аналогов

В MSSQL нет типов, представляющих только дату или только время, имеющихся в IB6.

Домены

В IB для создания доменов используется следующая конструкция:

create domain DCount numeric(15,4) default 1 not null;

Для MSSQL это будет выглядеть следующим образом:

create default ONE as 1

go

exec sp_addtype 'DCount', 'numeric(15,4)', 'NOT NULL'

go

exec sp_bindefault 'ONE', 'DCount'

go

Таблицы

Переносятся без проблем, следует только обратить внимание на замечания по контролю целостности данных (кстати, обратное преобразование будет затруднено, если вы будете использовать специфические для MSSQL типы (особенно для MSSQL2000)).

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

Перенос хранимых процедур – это наиболее трудоемкий процесс, т.к. придется переписывать все целиком. Но в правильно спроектированном трехзвенном приложении роль ХП должна быть сведена к минимуму. Основные трудности возникают при переводе ХП, возвращающих результирующий набор. Часть из них (не содержащие сложной бизнес-логики) может быть переведена в разряд представлений (view). Для остальных можно либо создавать временные таблицы на уровне соединения с СУБД, либо создавать постоянные таблицы и разграничивать данные в них по идентификатору подключения (SPID) (но тогда не забывайте их чистить :)). Если же вы решите ограничиться только MSSQL2000, то можете использовать тип "таблица" для возврата набора значений из процедуры. Рассмотрим несколько примеров перевода ХП. Процедура отчета о взаиморасчетах между клиентами:

create procedure REP_INOUT(FROM_DATE date, TO_DATE date)

 returns (FROM_ID integer, FROM_NAME varchar(180), TO_ID integer,

 TO_NAME varchar(180), FULL_SUM numeric(15,4))

as

begin

 for select FROM_ID, TO_ID, sum(DOC_SUM)

  from DOC_TITLE

  where DOC_DATE >= :FROM_DATE and DOC_DATE <= :TO_DATE

  group by FROM_ID, TO_ID

  into :FROM_ID, :TO_ID, :FULL_SUM

 do begin

  FROM_NAME = NULL;

  TO_NAME = NULL;

  select NAME

   from client

   where CLIENT_ID = :FROM_ID

  into :FROM_NAME;

  select NAME

   from client

   where CLIENT_ID = :TO_ID

  into :TO_NAME;

  if (FULL_SUM is NULL) then

   FULL_SUM = 0;

  suspend;

 end

end

^

Преобразуется в процедуру следующего вида:

create procedure rep_inout @from_date smalldatetime, @to_date smalldatetime

as

 select dt.from_id, dt.to_id, isnull(sum(dt.doc_sum), 0) as full_sum,

  c.name as from_name, c1.name as to_name

  from doc_title dt,

     client c,

     client c1

  where dt.doc_date >= @from_date

     and dt.doc_date <= @to_date

     and c.client_id = dt.from_id

     and c1.client_id = dt.to_id

  group by dt.from_id, c.name, dt.to_id, c1.name

go

Следующий пример. Процедура выводит список документов и полные имена клиентов:

create procedure LIST_DOC (FROM_DATE date, TO_DATE date)

 returns (DOC_ID integer, DOC_NUM varchar(40), DOC_DATE date,

  FROM_ID integer, TO_ID integer, FROM_NAME varchar(224),

   TO_NAME varchar(224), DOC_SUM numeric(15,4))

as

begin

 for select DOC_ID, DOC_NUM, DOC_DATE, FROM_ID, TO_ID, DOC_SUM

  from DOC_TITLE

  where DOC_DATE >= :FROM_DATE and DOC_DATE <= :TO_DATE

 into :DOC_ID, :DOC_NUM, :DOC_DATE, :FROM_ID, :TO_ID, :DOC_SUM

 do begin

  FROM_NAME = NULL;

  TO_NAME = NULL;

  execute procedure CLIENT_FULL_NAME (:FROM_ID)

  returning_values :FROM_NAME;

  execute procedure CLIENT_FULL_NAME (:TO_ID)

  returning_values :TO_NAME;

  suspend;

 end

end

^

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

Создадим для начала вспомогательную таблицу следующего вида:

create table pDoc_List

(

 SPID int,    --идентификатор подключения

 doc_id int,

 doc_num varchar(40),

 doc_date smalldatetime,

 from_id int,

 to_id int,

 doc_sum DSum,

 from_name varchar(224),

 to_name varchar(224)

)

go

В этой временной таблице мы будем хранить данные, отвечающие нашим критериям поиска. Для того, чтобы можно было отличить, какому клиенту предназначены данные, вводится столбец SPID, в котором мы будем хранить уникальный идентификатор подключения к БД (@@spid).

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

ПРИМЕЧАНИЕ

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

Вот код процедуры, заполняющей эту таблицу:

create proc list_doc @from_date datetime, @to_date datetime

as

 declare @from_name varchar(224)

 declare @to_name varchar(224)

 declare @from_id int

 declare @to_id int

 declare @doc_id int

 declare @doc_num varchar(40)

 declare @doc_date datetime

 declare @doc_sum dsum

 delete from pDoc_List

  where SPID = @@spid  --очищаем временную таблицу от предыдущих данных

 --вставляем нужные записи

 insert into pDoc_List(SPID, 

            doc_id,

            doc_num,

            doc_date,

            from_id,

            to_id,

            doc_sum,

            from_name,

            to_name

            )

  select @@spid,

      doc_id,

      doc_num,

      doc_date,

      from_id,

      to_id,

      doc_sum,

      '',

      ''

   from doc_title

   where doc_date >= @from_date and doc_date <= @to_date

     

 --создаем наиболее быстрый курсор для обработки записей

 declare list_docs insensitive cursor for 

 select doc_id, from_id, to_id       

  from pDoc_List

  where SPID = @@spid

 for read only              

 open list_docs

 fetch next from list_docs

  into @doc_id, @from_id, @to_id

 while @@fetch_status = 0

 begin

  select @from_name = '', @to_name = ''

  exec client_full_name @from_id, @from_name output

  exec client_full_name @to_id, @to_name output

  --заполняем поля, которых нет в основной таблице

  update pDoc_List

   set from_name = @from_name,

     to_name = @to_name

   where SPID = @@spid

      and doc_id = @doc_id

                    

  fetch next from list_docs

   into @doc_id, @from_id, @to_id

 end

 close list_docs

 deallocate list_docs

go

SQL-запрос, исполняемый на сервере приложений для передачи данных клиенту:

exec list_doc @from_date = :from_date, @to_date = :to_date

select * from pDoc_List where SPID = @@spid

ПРИМЕЧАНИЕ

При написании ХП следует обратить особое внимание на одновременную работу нескольких пользователей. Необходимо минимизировать влияние "тяжелых" (отчетных) процедур на работу клиентов (один из вариантов был показан выше).

Триггеры

Тут ничего сложного нет, необходимо только помнить, что триггеры в MSSQL запускаются только после действия (есть еще вместо (instead of), но это только в MSSQL2000).

Пример: предотвращение удаления клиента, если существуют документы с его участием (чтобы такой триггер не конфликтовал с ограничением ссылочной целостности, в MSSQL необходимо убрать foreign key с таблицы doc_title на client)

create trigger CLIENT_BEFORE_DELETE for CLIENT

before delete

as

begin

 if (exists (select * from DOC_TITLE

    where FROM_ID = OLD.CLIENT_ID))

 then

  exception EX_CLIENT_IN_DOC;

 if (exists (select * from DOC_TITLE

    where TO_ID = OLD.CLIENT_ID))

 then

  exception EX_CLIENT_IN_DOC;

end

^

Преобразуется в

create trigger CLIENT_AFTER_DELETE on CLIENT

for delete

as

 if (exists (select d.CLIENT_ID from

        DOC_TITLE dt, deleted d

        where dt.FROM_ID = d.CLIENT_ID))

 begin

  --чтобы сообщение было видно на клиенте

  raiserror ('Существует запись в документе', 16, 1)

  --необходимо ручками откатить транзакцию

  rollback transaction

 end

 if (exists (select d.CLIENT_ID from

        DOC_TITLE dt, deleted d

        where dt.TO_ID = d.CLIENT_ID))

 begin

  raiserror ('Существует запись в документе', 16, 1)

  rollback transaction

 end

go

Модификация сервера приложений.

Здесь основная часть переработки связана с переходом от IBX (InterBase Express) к ADO (ActiveX Data Object). Основные вещи, на которые следует обратить внимание:

Реализация транзакций на клиенте – в IBX это отдельный компонент, в ADO такая функциональность предоставляется методами TADOConnection. Еще небольшая рекомендация – аккуратно подходите к выбору уровня изоляции транзакций (чем меньше уровень изоляции, тем быстрее будет работать приложение).

Чтобы клиент работал без переделки с разными источниками данных, необходимо, чтобы типы данных полей совпадали. Например, в IBX для numeric(15, 4) по умолчанию подставляется TFloatField, а в ADO – TBCDField. Это единственное отличие, которое мне встретилось при переносе (но это не значит, что их вообще нет). Проблема решилась ручной установкой данного типа поля в TCurrencyField.

Перевод sql-выражений из синтаксиса IB в MSSQL.

Отличия, связанные с различиями структуры БД. Например, если будет реализовано каскадное удаление с помощью ХП, то придется реализовывать эту логику внутри сервера, чтобы оставить клиента нетронутым.

В качестве примера приведем перевод одной из процедур сервера приложений:

//Описание того, что делает данная процедура, читайте в статье Игнатьева.

//Код, работающий с IBX

function TrdmDoc.ApplyChanges: WideString;

begin

 lock;

 try

  FLastUpdateErrors := '';

  if FState = osInactive then

   raise Exception.Create('Документ не был создан либо открыт');

  with cdsTitle do

  begin

   Edit;

   FieldByName('DOC_SUM').asCurrency := CalcSum;

   Post;

  end;

  ibtDoc.StartTransaction; //ibtDoc – компонент транзакции

  if FState = osInsert then

  begin

   if cdsTitle.ChangeCount > 0 then

    cdsTitle.ApplyUpdates(-1);

   if cdsBody.ChangeCount > 0 then

    cdsBody.ApplyUpdates(-1);

  end;

  if FState = osUpdate then

  begin

   if cdsBody.ChangeCount > 0 then

    cdsBody.ApplyUpdates(-1);

   if cdsTitle.ChangeCount > 0 then

    cdsTitle.ApplyUpdates(-1);

  end;

  Result := FLastUpdateErrors;

  if Result = '' then

   ibtDoc.Commit

  else

  begin

   ibtDoc.Rollback;

  end;

 finally

  ibtDoc.Active := False; //DefaultAction = Rollback

  unlock;

 end;

end;

//Код, работающий с ADO

function TrdmDoc.ApplyChanges: WideString;

begin

 lock;

 try

  FLastUpdateErrors := '';

  if FState = osInactive then

   raise Exception.Create('Документ не был создан либо открыт');

  with cdsTitle do

  begin

   Edit;

   FieldByName('DOC_SUM').asCurrency := CalcSum;

   Post;

  end;

  adcDocs.BeginTrans;    //явные транзакции задаются на уровне соединения

  if FState = osInsert then //а не отдельным компонентом

  begin

   if cdsTitle.ChangeCount > 0 then

    cdsTitle.ApplyUpdates(-1);

   if cdsBody.ChangeCount > 0 then

    cdsBody.ApplyUpdates(-1);

  end;

  if FState = osUpdate then

  begin

   if cdsBody.ChangeCount > 0 then

    cdsBody.ApplyUpdates(-1);

   if cdsTitle.ChangeCount > 0 then

    cdsTitle.ApplyUpdates(-1);

  end;

  Result := FLastUpdateErrors;

  if Result = '' then

   adcDocs.CommitTrans

  else

  begin

   adcDocs.RollbackTrans;

  end;

 finally

  unlock;

 end;

end;

Заключение

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

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

Все вопросы, замечания, исправления, дополнения направляйте на kapusto@mail.ru

Хочу выразить признательность Игнатьеву Роману, Павлу Шмакову за советы, критику и настойчивость.


Александр Капустин Введение В данной статье рассматриваются проблемы, связанные с миграцией приложения MIDAS с одной СУБД на другую. Рассмотрим это на примере переноса приложения, описанного в статье Романа Игнатьева "MIDAS: практика применен

 

 

 

Внимание! Представленный Реферат находится в открытом доступе в сети Интернет, и уже неоднократно сдавался, возможно, даже в твоем учебном заведении.
Советуем не рисковать. Узнай, сколько стоит абсолютно уникальный Реферат по твоей теме:

Новости образования и науки

Заказать уникальную работу

Свои сданные студенческие работы

присылайте нам на e-mail

Client@Stud-Baza.ru