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

Оценивая СУБД по поставщику, необходимо учесть следующие факторы [4]:

• маркетинговую стратегию - умение поставщика выбирать соответствующие целевые рынки, а также организовывать партнерство для расширения маркетинговых возможностей продукта;

• внедрение инноваций - разработка новых технологий, вложения средств в научные исследования, влияние на развитие рынка, способность поставщика внедрить в СУБД новую функциональность;

• географическую стратегию - способность компании использовать свои ресурсы в различных географических регионах, открывать филиалы и организовывать партнерство.

• стабильность работы производителя.

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

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

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

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

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

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

Сами по себе БД не являются готовыми тиражными решениями. Все современные СУБД имеют дополнительные программные средства. Их наличие и стоимость также являются критерием выбора СУБД. Например, у фирмы Oracle имеется множество дополнительного программного обеспечения, но, к сожалению, его стоимость тоже высока. И только очень крупные компании могут себе позволить купить вместе с СУБД еще и дополнительные программные средства (например, Server Application Oracle – сервер приложений для создания web-порталов).

Применяя те или иные языки программирования, среды и инструменты разработки, готовые компоненты третьих фирм и модули, поставляемые производителем сервера БД, можно существенно увеличить функциональность создаваемых БД [7]. Но при этом могут появляться драйверы ODBC и OLEDB «третьих» производителей, которые хотя и позволяют работать с БД, но не гарантируют отсутствия проблем при обработке специфических запросов.

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

• удовлетворенность надежностью БД (по шкале от 1 до 9);

• продолжительность последнего незапланированного простоя системы (нет, до 10 мин, 11-60 мин, 1 - 2 часа, более 2 часов);

• удовлетворенность масштабируемостью БД (по шкале от 1 до 9);

• время отклика при первоначальной регистрации в системе, выполнении наиболее типичных транзакций, запросов;

• количество одновременно работающих пользователей на одном сервере БД;

• количество пользователей на одного администратора БД.

Таблица 2 – Характеристики корпоративных СУБД

Компании	СУБД	Краткая характеристика
Зарубежные продукты
Borland	InterBase	SQL-совместимая реляционная, ОС - Windows, Linux и Solaris.
Computer Associates	Jasmine, Ingres II	Объектно-ориентированная СУБД, совместима с технологиями XML и Java. Распределенная реляционная СУБД и объектно-ориентированная среда разработки приложений в архитектуре клиент/сервер. ОС - Unix, Linux, мейнфреймах, VMS, OS/2, Windows, NetWare.
IBM	DB2 Universal Database, Informix	Мультимедийная, Web, ОС - Unix, Linux и Windows, аппаратные платформы - zSeries, iSeries, VSE и VM. СУБД для систем масштаба предприятия и рабочей группы, обеспечивает работу с очень крупными БД в условиях дефицита ресурсов. Используемые языки - Java, SQL 2000
InterSystems	Cache’	Постреляционная СУБД, включающая сервер многомерных данных и средство обработки запросов на языке SQL. ОС - Unix, Mac OS, Linux, Windows (32- и 64-разрядные версии).
Microsoft	SQL Server	Реляционная СУБД для управления данными в масштабе предприятия, поддерживает технологии XML и Интернет, обладает встроенным средством анализа и извлечения данных, интегрированным с MS Office, ОС - Windows. Используемый язык Transact-SQL, XML
Oracle	Oracle	СУБД для масштабной обработки транзакций (OLTP), хранилищ данных с высокой интенсивностью потока запросов и ресурсоемких Интернет-приложений. ОС - Unix, Windows и Linux. Последняя версия поддерживает Grid-вычисления. Используемые языки Java, Delphi PL/SQL, XML
Software AG	Adabas	Постреляционная, поддерживает различные модели данных, работает на мейнфреймах, ОС - Unix, Linux, OpenVMS и Windows
Sybase	Sybase Adaptive Server Enterprise	СУБД масштаба предприятия для централизованной обработки критически важной информации, работает на платформах Unix и Linux. Компактная, полноценная реляционная СУБД для рабочих групп, мобильных и встроенных вычислений. Используемые языки Java, Transact-SQL
Teradata	Teradata Database	Предназначена для создания хранилищ данных, ОС - Windows 2000 Server, Windows 2000 Advanced Server, Windows .NET Server и ряда версий UNIX
Microsoft	dBASE III Plus	ОС Windows. Создаваемые ею файлы импортируются СУБД FoxPro, Paradox, MS Access, а также пакетами прикладных программ MS Excel, Surfer, Grapher и др.
Отечественные продукты
Рэлэкс	Линтер	Реляционная СУБД, имеющая сертификат Гостехкомиссии при Президенте РФ на соответствие 2 классу защиты информации от несанкционированного доступа, ОС - Unix, Linux, QNX, VAX/VMS, OpenVMS, DOS, Windows, NetWare, OS/2
ВНИИНС	Паллада	Объектно-ориентированная СУБД, предназначенная для АСУ вооруженных сил, функционирует в среде ОС МСВС и ОЛИВИЯ
СУБД с открытым исходным кодом
MySQL AB	MySQL	Компактная, быстродействующая реляционная СУБД для малых и средних предприятий, ОС - Linux, Mac OS X, Unix и Windows
Сообщество PostgreSQL	PostgreSQL	Реляционная СУБД, имеет многие возможности, которые реализованы в крупных коммерческих продуктах, ОС - Unix, Windows и NetWare

Сравнение СУБД ACCESS, MySQL, Oracle

Объём памяти на жёстком диске необходимый для самой СУБД: ACCESS (OfficeXP) – 530 Мбайт, Oracle – >1 Гбайт, для работы с MySQL через Интернет необходим только браузер, а для работы локально нужен ещё web-сервер, поддерживающий MySQL и PHP (например, Apache – 8Мбайт). Размер БД в формате соответствующем каждой СУБД: ACCESS – 1,73 Мбайт, MySQL – 113 Кбайт, Oracle – размер определяется не содержанием самой базы, а задаваемым табличным пространством.

Оперативная память, используемая СУБД при работе с той же БД: ACCESS – 4528 Кбайт, сервер Apache + Internet Explorer – 28612 Кбайт (из них Internet Explorer – 11660 Кбайт).

Быстродействие: при работе локально разница между временем выполнения запроса в ACCESS и временем выполнения аналогичного запроса в MySQL практически неощутима (десятые доли секунды); при работе же с MySQL через Internet скорость зависит от таких параметров как трафик сети, удалённость и быстродействие сервера и прочее.

Простота использования: Интерфейс СУБД ACCESS очень нагляден, содержит хорошую систему помощи и опции «мастеров» создания и заполнения, это всё в совокупности позволяет даже неопытному пользователю, не имеющему навыков работы с какими-либо СУБД, довольно таки быстро научиться создавать и управлять БД. В СУБД MySQL – не смотря на то, что приходится прописывать всё в ручную, особых трудностей тоже нет, особенно, если пользователь обладает хотя бы какими-то навыками программирования и работы с БД. СУБД Oracle требует ее изучения в течение большего, по сравнению с ACCESS и MySQL, времени.

Таблица 3 - Практические характеристики БД MS SQL и Oracle []

Характеристики	Microsoft SQL Server	Oracle
Удобство и простота настройки	Интуитивно понятный интерфейс	Медленный графический интерфейс, требуется много оперативной памяти из-за работы Сборщика мусора
ОС	Windows	Windows или UNIX
Мин требования для аппаратного обеспечения (при загрузке)	HDD – 80 Мбайт, RAM – 15 Мбайт	HDD - 1.3 Гбайт, RAM – 150 Мбайт
Скорость развёртывания	Установка занимает не больше 10 мин	Установка занимает не меньше 30 мин
Скорость загрузки	Максимум 10 с	Минимум 3 мин
Производительность	Хорошо	Хорошо
Конкурентный доступ	Хорошо	Отличный
Число пользователей	Удовлетворительно	Не ограничено
Большие БД	Поддерживает средне	Отлично
Готовность	Отлично	Отлично
Административное управление	Хорошо	Отлично
Графические инструменты	Отлично	Хорошо
Простота обслуживания	Отлично	Отлично
Механизм данных	Хорошо	Отлично
Работа с несколькими процессорами	Приемлемо	Отлично
Функция соединения и выбор индексов	Отлично	Отлично
Одновременный доступ нескольких пользователей	Хорошо	Отлично
Обработка мультимедиа-данных	Плохо	Отлично
Подключение к Интернет	Хорошо	Отлично
Обработка аудио, видео, изображений	Плохо	Отлично
Поиск по всему тексту	Хорошо	Отлично
Функциональная совместимость	Хорошо	Хорошо
Сопряжение с другими БД	Хорошо	Хорошо
Единая регистрация	Хорошо	Хорошо

Примечание: Тестирование производилось на компьютере с характеристиками CPU - 750 MHz AMD DURON, RAM- 128 Мбайт, ОС - Windows 2000 Professional.

Основным минусом СУБД Oracle, DB2 и Microsoft SQL Server является их высокая стоимость. Кроме того, они являются закрытыми, что не всегда подходит компаниям с высокими требованиями к безопасности. Это ограничивает также возможности интеграции данных.

Сравнение наиболее важных характеристик и возможностей БД MySQL и PostgreSQL приведено в табл. 4. Из таблицы видно, что PostgreSQL предлагает полные особенности и возможности традиционных приложений БД, в то время как MySQL сосредотачивается на более быстром выполнении веб-приложений.

Таблица 4 - Сравнение MySQL и PostgreSQL

Особенности	PostgreSQL	MySQL
ANSI SQL совместимость	Близка к стандарту	Следует не всем стандартам ANSI SQL
Скорость работы	Медленнее	Быстрее
Вложенная команда Select	Да	Нет
Транзакации	Да	Да, должен использоваться тип таблицы InnoDB
Ответ БД	Да	Да
Поддержка внешних ключей	Да	Нет
Представления	Да	Нет
Хранимые процедуры	Да	Нет
Триггеры	Да	Нет
Unions	Да	Нет
Полные Joins	Да	Нет
Ограничители целостности	Да	Нет
Поддержка Windows	Да	Да
Вакуум (очистка)	Да	Нет
ODBC	Да	Да
JDBC	Да	Да
Различные типы таблиц	Нет	Да

Для веб-приложений главное это производительность и скорость, поэтому MySQL будет лучшим выбором, потому что она быстра и разработана для того, чтобы хорошо работать с веб-серверами. Однако, если создавать приложение, которое требует выполнения транзакаций и наличия внешних ключей, лучшим выбором станет PostgreSQL. MySQL не полностью совместима с ANSI SQL стандартом, PostgreSQL ближе к ANSI SQL стандарту, MySQL ближе к ODBC стандарту. Некоторые плюсы использования СУБД MySQL:

• MySQL относительно быстрее PostgreSQL;

• дизайн и планирование БД несколько проще;

• можно создать простой веб сайт с использованием базы;

• ответы на запросы MySQL были хорошо протестированы;

• нет нужды использовать методы очистки данных.

СУБД PostgreSQL имеет много преимуществ над MySQL, например, используются внешние ключи, триггеры и представления. Они позволяют скрывать сложность БД от приложения, избегая создания сложных команд SQL. Несколько причин использовать PostgreSQL:

• наличие функций экспорта-импорта данных из СУБД Oracle, Sybase, MS SQL;

• использование процедурных языков на сервере;

• выполнение транзакций;

• использование хранимых процедур.

• использование пространственных данных.

• использование индексов;

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

СУБД PostgreSQL Plus Advanced Server — это СУБД корпоративного уровня с гарантированной поддержкой производителя. СУБД PostgreSQL в настоящее время лидер среди СУБД с открытым исходным кодом. Также она хорошо совместима с СУБД Oracle, MS SQL, MySQL, Sybase (поддержка процедур, триггеров, пакетов, типов данных, функций и т.д.), что дает возможность достаточно быстро мигрировать на СУБД PostgreSQL.

Несмотря на некоторые преимущества Oracle, при использовании на не очень больших объектах особой разницы между Oracle и MS SQL Server нет. В таком случае начинают играть весомую роль другие критерии выбора:

• квалификация персонала в работе с конкретными СУБД;

• размер используемых ресурсов;

• количество пользователей;

• исторически сложившаяся ситуация на предприятии;

• партнерские отношения;

• стоимость СУБД (в зависимости от числа пользователей или процессоров, на которых она установлена).

Расчет совокупной стоимости владения СУБД [6]

Совокупная стоимость владения СУБД включает стоимость:

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

• сопровождения СУБД, которая определяется заработной платой сотрудников, ответственных за обслуживание и администрирование БД;

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

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

Для сравнения совокупной стоимости владения СУБД Oracle, DB2 и MS SQL Server и PostgreSQL будем проводить расчеты затрат для случая разворачивания СУБД на двух серверах, на каждом из которых имеется два CPU архитектуры x86 стоимостью — 100000 рублей. В качестве периода владения выбран один год. Стоимость лицензии и поддержки для выбранных СУБД приведены в табл.5.

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

Таблица 5 - Стоимость СУБД (в рублях)

Наименование СУБД	Лицензия	Поддержка	Итого
PostgreSQL	0	636 492	636 492
MS SQL	2 902 200	856 149	3 758 349
DB2	4 368 000	1 030 848	5 398 848
Oracle	7 080 000	1 837 968	8 917 968

Таблица 6 - Стоимость сопровождения СУБД (в рублях)

Наименование СУБД	Среднемесячная зарплата	Годовой ФОТ
PostgreSQL	70 000	840 000
MS SQL	80 000	960 000
DB2	90 000	1 080 000
Oracle	80 000	960 000

В качестве ОС для СУБД Oracle, PostgreSQL и IBM DB2 выбрана ОС Red Hat Enterprise Linux с уровнем поддержки Standard. Для MS SQL в качестве ОС взята Microsoft Windows Server Enterprise. Исходя из указанных предположений, получим следующие результаты расчета стоимости платформы для СУБД (табл.7).

Таблица 7 - Стоимость платформы для СУБД (в рублях)

Наименование СУБД	Оборудование		ОС		Итого
	Стоимость	Поддержка	Стоимость	Поддержка
PostgreSQL	200 000	59 000	0	63 720	322 720
MS SQL	200 000	59 000	128 600	37 937	425 537
DB2	200 000	59 000	0	63 720	322 720
Oracle	200 000	59 000	0	63 720	322 720

Основываясь на результатах предыдущих расчетов, можно оценить совокупную стоимость владения рассматриваемыми СУБД в течение первого года как сумму всех составляющих. Также приведем результаты расчета TCO в течение 3 лет. Результаты представлены в табл.8.

Таблица 8 - Совокупная стоимость владения СУБД (в рублях)

Наименование СУБД	в течение 1 года	в течение первых 3 лет
PostgreSQL	1 799 212	4 997 636
MS SQL	5 143 886	8 970 058
DB2	6 801 568	11 268 704
Oracle	10 200 688	16 042 064

При расчете для двух серверов с двумя процессорами получаем, что PostgreSQL обходится дешевле Oracle в 3-5 раз, и эта разница будет только увеличиваться при разворачивании более масштабных БД. При внедрении открытого программного обеспечения надо учитывать стоимость владения TCO, а не стоимость лицензий. Поэтому всё упирается в вопрос масштаба. Все затраты и на проект уже сделаны, поэтому каждый новый центр будет давать чистую экономию.

Миграция приложений и баз данных

Миграция приложений и баз данных это сложный, дорогостоящий и, зачастую, рискованный процесс. В первую очередь это связано с тем, что при разработке приложений для СУБД используются различные специфические функции, не входящие в стандартный SQL. Кроме того, ожидаемые выгоды от миграции часто не оправдывают затрат на переподготовку специалистов и работы, связанные с переписыванием приложений и тестированием произведенных изменений [http://www.pcweek.ru/upload/iblock/fd0/bureausolomatina-3.pdf].

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

Таблица 9 - Стратегия внедрения СУБД Postgres

Стратегия	Преимущества
Разработка-внедрение новых приложений на СУБД PostgreSQL	Значительное сокращение затрат на некритичные системы Использование имеющихся знаний и опыта работы с Oracle Очень низкий риск неудачи
Использование СУБД PostgreSQL в качестве сервера репликации с Oracle	Значительное сокращение затрат Использование преимуществ PostgreSQL Использование имеющихся знаний и опыта работы с Oracle Повышение производительности OLTP приложений
Миграция некритичных приложений с СУБД Oracle на PostgreSQL	Значительное сокращение затрат Использование имеющихся знаний и опыта работы с Oracle Низкий риск неудачи
Миграция критически важных приложений с СУБД Oracle на PostgreSQL	Наибольшее сокращение затрат Использование имеющихся знаний и опыта работы с Oracle Гибкость развертывания

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

Производители БД сознательно создают специфические расширения SQL для придания отличительных черт своему продукту. PostgreSQL распознает расширения SQL, созданные Oracle, например, decode(), таблица DUAL и ROWNUM.

Процедурный язык СУБД PostgreSQL (PL/pgSQL) совместим с языком PL/SQL от Oracle для триггеров, хранимых процедур, пакетов, функций и других расширений СУБД, например, распознание событий ожидания (Wait Events). В итоге, необходимость переподготовки разработчиков и переписывание приложений сводится к минимуму, экономя время и затраты на миграцию, а также снижая риск неудачи проекта.

Такие инструменты, как SQL*Plus, SQL*Loader, DBA Management Server и DBLinks, также поддерживаются в PostgreSQL. Кроме того, поддерживаются наиболее часто используемые служебные представления Oracle. Поэтому администраторам БД не требуется проходить переподготовку, и они могут полноценно использовать ранее накопленный опыт работы с Oracle.

PostgreSQL поддерживает наиболее распространенные языки программирования, используемые для создания приложений для Oracle. Также PostgreSQL имеет встроенную поддержку Oracle Call Interface (OCI), тем самым гарантируя работу приложений, написанных на C или C++.

Для упрощения и ускорения процесса миграции больших баз данных PostgreSQL предоставляет автоматизированные инструменты для перемещения объектов СУБД Oracle (схемы, таблицы, данные, пакеты, триггеры, хранимые процедуры, функции и т.д.).

Перед началом миграции данных целесообразно оценить параметры будущей БД:

• факторы совместимости БД (влияют на трудоемкость миграции);

• длительность миграции;

• экономические выгоды от проекта.

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

• параметры объектов;

• специфические особенности;

• синтаксис;

• пакеты;

• параметры развертывания.

На основе этих категорий составляется консолидированный индекс совместимости БД, который помогает достаточно быстро оценить возможность миграции конкретного экземпляра БД в Oracle в PostgreSQL. Среди параметров объектов БД наиболее интересны структура и размер таблиц и индексов, используемые ограничения, структура представлений. К тому же необходимо учитывать наличие таких опций Oracle, как сжатие данных или индекс-таблицы.

Трудоемкость миграции сильно зависит от использования в приложении специфических особенностей экземпляра БД Oracle измерения, хранимые шаблоны, Advanced Queuing, пространственные объекты, XML-объекты.

Особенности использования конструкций языка PL/SQL в БД Oracle требуют разделить их на три части: поддерживаются, имеют альтернативу и не поддерживаются в PostgreSQL. Перед миграцией необходимо определить, какие из встроенных пакетов Oracle используются в хранимых процедурах, триггерах и функциях.

Параметры развертывания характеризуют степень использования в развернутом экземпляре Oracle таких функций, как DBLink, репликации, Real Application Cluster (RAC), создание резервных БД, ASM (automated storage management) и AWR (automatic workload repository).

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

• структура и размер БД;

• структура и размер клиентского приложения;

• знания и опыт технических специалистов;

• наличие других текущих проектов;

• организационные ресурсы и бюджет;

• временные рамки;

• имеющаяся серверная и сетевая инфраструктура.

Экономические выгоды от проекта в первую очередь связаны с сокращением затрат на содержание СУБД и зависят от следующих факторов:

• выбранная стратегия миграции;

• конкретные БД и приложения для миграции;

• количество переносимых экземпляров;

• параметры серверной платформы.

После того как проведена оценка параметров проекта на основе факторов совместимости БД, рассчитана длительность проекта и экономические выгоды, принимается решение о проведении миграции базы данных с Oracle на PostgreSQL.

Наиболее типичными ошибками при миграция структур данных являются:

• конфликт зарезервированного слова,

• проблема в различной реализации функций,

• неподдерживаемые на данный момент функции.

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

Также существует ряд функций Oracle, которые пока не поддерживаются в PostgreSQL и, соответственно, не могут быть перенесены. Например, Automatic Storage Management (ASM) или Flashback database. Высокая совместимость PostgreSQL с большинством расширений SQL, используемых в Oracle, позволяет встроенным в приложения SQL запросам работать практически без изменений.