Роман Викторович — Как была решена проблема потерянных данных при переходе на новую ИС на базе Firebird

Исторически так сложилось, что в нашей организации в качестве СУБД использовался сервер MS SQL Server. Более 10 лет разрабатывалась и сопровождалась информационная система, разработанная на MS Access, на смену ей приходили новые разработки.

Но вот наступил 2010 год — год 15-летия компании. И высшее руководство решило преподнести себе подарок — приобрести уже готовую и годами отточенную информационную систему, которая бы закрывала большинство участков бизнеса. В качестве такой системы была выбрана КИС «Восточный экспресс».

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

• когда главная цель ввязаться в драку, поставщики КИС, на вопрос: «Сможем ли мы наследовать все данные из старых информационных систем?»
• отвечали: «Да, естественно. Нами разработан ряд форматов для загрузки данных из других систем. Поэтому данные будут загружены».

Произошла загрузка! И, о боже! Некоторые данные в результате импорта были искажены или потеряны. Как найти разницу? Если исходные данные расположены на MS SQL Server, а целевая СУБД — Firebird. Поставщики Восточного экспресса пожимают плечами: «Видимо экспорт данных из старой системы был с ошибками». Т. е. мы сами виноваты, когда готовили транспортные файлы.

Хорошо! Попытаемся создать связанный сервер на MS SQL Server и провести сверку данных. Опа! И тут неудача, отсутствует OLE DB Provider для Firebird или InterBase. Так, поищем в интернете, поспрашиваем всех и каждого. Ага, есть следующие варианты:

• использовать Firebird ODBC Driver
• использовать IBProvider

Были и другие варианты, и они были перепробованы, но отпали на этапе предварительного исследования. А вот первые два варианта прошли проверку — связанный сервер создается, данные вытягиваются. Правда, IBProvider платный, ну ладно, нам ненадолго, будем использовать Trial, а лучше вообще пока использовать Firebird ODBC Driver.

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

Решили потестировать IBProvider! Пусть Trial, но если все будет хорошо — можно и купить. Ого! Тот же самый запрос, выполняется несколько секунд. Надо же, отлично! Сделали сверку, выправили то, что не сошлось, тут как раз и период использования закончился. Плюс ко всему, новую КИС Восточный экспресс было решено перенести на новый 64х разрядный сервер. Наверняка, для 64х разрядов, данный провайдер не предназначен. Почитали, попробовали. Работает!

Я выбрал IBProvider, потому что, это был единственный из найденных способов, позволивших решить нам нашу проблему.

Мне оказались полезны следующие возможности IBRovider:

• Поддержка всех версий серверов Firebird/InterBase,
• Легкость масштабирования, Поддержка 64 битных приложений
• Технология MS SQL Linked Server и технология обновляемых множеств
• Встроенный конвертор типов данных.

Описание действующей системы:

• MS SQL Server 2005, до 500 подключений
• Firebird 2.0, в данный момент пока до 10 подключений

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