Миграция с одной СУБД на другую [закрыто]
https://stackoverflow.com/questions/290970
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Есть ли у кого-нибудь опыт миграции с одной СУБД на другую?Если вы это сделали, то почему вы это сделали?Функции?Расходы?Корпоративная директива?
Время от времени я работал с администраторами баз данных, которые настаивали на том, чтобы мы не использовали функции, специфичные для СУБД (например, хранимые процедуры CLR в SQL Server). при необходимости переключимся на другую СУБД.Но до сих пор меня ни разу не попросили переключиться.
Решение
На мой взгляд, глупо не использовать все возможности БД, которые вы используете. Изменение СУБД независимо от того, сколько функций вы используете, будет сложным. Между системами существуют незначительные различия (например, некоторая дата записи и некоторая дата и время записи), которые могут вызвать сильную головную боль. Нет такой вещи, чтобы просто перейти на новую базу данных.
С точки зрения бизнеса предстоит проделать большую работу. Анализ новых БД для изменения. Выяснить влияние изменения базы данных на новую систему. После разработки измените существующие системы, протестируйте изменения и т. Д. Этот список можно продолжать и продолжать. Такое переключение в корпоративной системе занимает месяцы, если не годы. Последнее место, где я работал, - это поменять базу данных, и на это у нас ушло 11 месяцев, и около 2 миллионов долларов на оплату услуг консультантов, оборудования, программного обеспечения и сотрудников. Это большое дело. Если кто-то говорит, что не следует использовать функции, потому что это "может" случится когда-нибудь, и это будет легче сделать, Скорее всего, этот человек оторвался от своего рокера. Дополнительное количество времени и денег, которые потребуются для преобразования этих функций, ничтожно по сравнению со всем остальным (скорее всего). ИМО, если это сэкономит время и деньги, теперь покупайте с использованием этих функций, тогда это лучший курс действий.
Мы сделали это, потому что системы, которые мы использовали на старых dbms, были слишком большими. Было слишком много данных, и нам нужно было нечто более мощное. Кроме того, он больше не поддерживается.
Другие советы
Я работал в компании в течение нескольких лет, чей продукт поддерживал Oracle или SQL Server. Мы поддерживали модель в Erwin и генерировали из нее сценарии схемы, триггеры и пакеты Oracle. Пакеты использовались для того, чтобы триггеры Oracle работали аналогично триггерам SQL Server (с логическими «вставленными» и «удаленными» таблицами). Мы сохранили два набора сценариев хранимых процедур.
С этим беспорядком у меня под рукой, я бы посоветовал вам переносить большие проекты, при условии, что вы можете сделать свой уровень данных полностью отделенным от любого логического кода. Если вы можете это сделать, то вы можете реализовать любые функции базы данных, которые ускорят работу приложения на уровне данных, не затрагивая ваше основное приложение.
Много раз менял.Главным образом потому, что «принудительное преобразование» — старый продукт больше не поддерживается или больше не подходит.
- DB2 для Oracle.Данные до UDB были сохранены и перенесены в Oracle.
- MS-доступ к Oracle.Продолжение использования внешнего интерфейса Access для таблиц Oracle.
- Оракул за Оракулом.Думаю от 6 до 8...
"зачем ты это сделал?" Не функции.Не стоимость.Во всех случаях что-то сломано.
- Старый продукт больше не работает.Либо обновление ОС, либо что-то еще привело к прорыву устаревшего продукта.
- Старый продукт не масштабировался.
Переключение редко является чем-то, что вы решаете сделать.Вам приходится это делать, когда поставщики прекращают свою деятельность (Ingres сделал это однажды) или прекращают поддержку вашей версии (Microsoft делает это часто).
Тогда, конечно, кризис.Усугубляется технической сложностью изменений триггеров и хранимых процедур.Если бы это были только данные, это не было бы большим кризисом.Сохраните дамп в какую-нибудь стандартную форму (например, CSV), перезагрузите, и все готово.
Что еще более важно, чем больше «материалов» (хранимых процедур, триггеров и т. д.) в базе данных, тем больше ваше прикладное программное обеспечение становится запутанной кучей сложных для понимания (и трудно поддерживаемых) элементов.Нет ничего более неприятного, чем неделями ждать, пока кто-нибудь найдет имя хранимой процедуры.Если бы это был код VB, каждый имел бы к нему доступ.Но поскольку он оказался в базе данных, он стал, как это ни парадоксально, менее заметным.Код есть код, и его следует хранить отдельно от данных.
Видеть Куда поместить свой код — база данных vs.Приложение? для получения дополнительной информации по этой теме.
Я участвовал в нескольких проектах по переносу данных из одной базы данных в другую. В каждом случае это были перенесенные данные, а не RDMBS. Если приложение работает, тогда не будет никакого давления для переключения баз данных ради переключения. Стимулом для миграции обычно является то, что данные старой системы либо устарели, либо несовместимы, либо и то, и другое, и это также дает возможность переключать RDBMS.
Наиболее вероятным изменением является объединение справочных данных (сотрудников, клиентов и т. д.) в существующую основную базу данных (для согласованности и простоты использования), а затем изменение всех других таблиц так, чтобы ключи указывали на новые справочные данные. Это требует схемы и соответствующего изменения кода вверх и вниз по стеку. Это миграция данных, а не миграция базы данных. И, скорее всего, вы захотите воспользоваться возможностью добавить данные, стандартизировать имена или (де) нормализовать таблицы и т. Д.
В результате, эти проекты почти всегда оказывают огромное влияние на данные, схему и код, и любая работа, необходимая для, скажем, перевода T-SQL в PL-SQL, будет незначительной частью. проекта. Так что, если вы платите за хорошую СУБД, используйте все это. В противном случае все равно, что не использовать багажник или бардачок вашего нового автомобиля, чтобы вам было удобнее менять автомобиль при покупке нового.
Еще один момент (в поддержку С. Лотта). В зависимости от вашей среды разработки вашим разработчикам может быть нелегко разрабатывать или даже просматривать хранимые процедуры. Разделение кода приложения между двумя различными наборами инструментов разработки и средами исполнения может стать сложным, и это может затруднить поиск квалифицированных сотрудников.
Я не думаю, что это аргумент против хранимых процедур, но это определенно необходимо учитывать при принятии решения о том, где должен находиться код для данного компонента ваших приложений.
Мы сделали переход с HP3000 на Oracle. Это стоило нам 25 миллионов долларов, а также добавило стоимость потери 200 миллионов долларов из-за такой спешки, что они не думали о том, что делают. Кроме того, я нашел много мест, которые просто рассматривают это как движение. Остальное они выяснят позже ....... намного позже.
