Перенос из одной СУБД в другую

Question

Есть ли у кого-нибудь опыт миграции из одной СУБД в другую? Если вы это сделали, зачем вы это сделали? Особенности? Стоимость? Корпоративная директива?

Время от времени я работал с администраторами баз данных, которые настаивали на том, что мы не используем функции, специфичные для СУБД (например, хранимые процедуры CLR в SQL Server). Точка DBA, если мы будем использовать эти функции, будет с этим сложнее переключиться на другую СУБД, если придется. Но до сих пор меня никогда не просили переключиться.

Answer 1

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

С точки зрения бизнеса есть много работы, которую нужно выполнить. Анализ новых dbs для изменения. Выяснение влияния изменения dbs на новую систему. Наличие изменений в изменении существующих систем, тестирование изменений и т. Д. Список можно продолжать и продолжать. Создание такого переключателя на корпоративной системе занимает несколько месяцев, если не годы. Последнее место, где я работало, должно было изменить dbs, и для этого потребовалось 11 месяцев для этого, и около 2 миллионов долларов для консультантов, оборудования, программного обеспечения и зарплаты сотрудников. Это большая сделка. Если кто-то говорит не использовать функции, потому что это может произойти когда-нибудь, и это будет легче сделать, Скорее всего, этот человек отключен от своего рокера. Дополнительное количество времени и денег, которое потребуется для преобразования этих функций, является незначительным по сравнению со всем остальным (скорее всего). ИМО, если это сэкономит время и деньги, теперь покупайте с помощью этих функций, тогда это лучший способ действий.

Мы сделали это, потому что системы, которые мы использовали на старых dbms, были слишком большими. Было слишком много данных, и нам нужно было что-то гораздо более мощное. Кроме того, он больше не поддерживался.

Answer 2

Коммутируемый много раз. В основном потому, что «Involuntary Conversion» - старый продукт больше не поддерживается или больше не подходит.

• DB2 to Oracle. Данные предварительного UDB были сохранены и перемещены в Oracle.
• MS-доступ к Oracle. Продолжение с использованием интерфейсов Access перед Oracle.
• Oracle для Oracle. 6-8, я думаю ...

«Почему вы это сделали?» Не функции. Не стоит. Во всех случаях что-то нарушается.

• Старый товар больше не работает. Либо обновление ОС, либо что-то еще привело к перерыву в устаревших продуктах.
• Старый товар не масштабируется.

Переключение редко - это то, что вы решите сделать. Это вынуждает вас, когда вендоры выходят из бизнеса (Энгр сделал это один раз) или прекратил поддерживать вашу версию (Microsoft делает это часто).

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

Что еще более важно, тем более «материал» (хранимые процедуры, триггеры и т. Д.) в базе данных, тем больше ваше прикладное программное обеспечение становится запутанной кучей труднодоступных (и труднодоступных) kludges. Нет ничего такого расстроенного, как ожидания недель, когда кто-то отслеживает имя хранимой процедуры. Если бы это был код VB, у всех был бы доступ к нему. Но так как это было в базе данных, это стало парадоксальным - менее заметным. Код - это код и должен храниться вдали от данных.

См. Where to put your code - Database vs. Application? для получения дополнительной информации по этой теме.

Answer 3

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

Наиболее вероятным изменением является объединение ссылочных данных (сотрудников, клиентов и т. Д.) В существующую основную базу данных (для обеспечения согласованности и простоты использования), а затем изменить все остальные таблицы, чтобы клавиши указывали на новые справочные данные. Для этого требуется схема и соответствующие изменения кода вверх и вниз по стеку. Это миграция данных, а не миграция базы данных. И, скорее всего, вы захотите воспользоваться возможностью добавления данных или стандартизации имен или (de) -нормализовать таблицы и т. Д.

Таким образом, эти проекты почти всегда оказывают огромное влияние на данные, схема и код, а также любая работа, требуемая для перевода T-SQL в PL-SQL, будет тривиально небольшой частью проекта. Поэтому, если вы платите за хорошую РСУБД, используйте все это. Иначе было бы не использовать багажник или бардачок вашего нового автомобиля, чтобы было легче переключать автомобили, когда вы покупаете новый.

Answer 4

Я работал в компании в течение нескольких лет, продукт которой поддерживал Oracle или SQL Server. Мы сохранили модель в Erwin и сгенерировали ее сценарии, триггеры и пакеты Oracle. Пакеты были использованы для того, чтобы триггеры Oracle работали одинаково с SQL Server (с логическими «вставленными» и «удаленными» таблицами). Мы сохранили два набора сценариев хранимых процедур.

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

Answer 5

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

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

Answer 6

Мы сделали это перенос HP3000 в Oracle. Это стоило нам 25 миллионов долларов, а также добавило стоимость потери 200 миллионов долларов данных из-за просто такой чертовой спешки, что они не думали о том, что они делают. Также я нашел много мест, которые просто рассматривают его как просто шаг. Позже они выяснят позже ... намного позже.