MS SQL - миграция MySQL в устаревшем webapp

Question

Я хочу перенести базу данных устаревшего веб-приложения из SQL Server в MySQL. Каковы ограничения MySQL, на которые я должен обратить внимание? И что все элементы будут частью всеобъемлющего контрольного списка, прежде чем перейти к фактическому изменению кода?

Answer 1

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

Как вы получаете доступ к данным через sps или динамические запросы из базы данных? Проверьте каждый запрос, запустив его в новой базе данных разработчиков и убедитесь, что они все еще работают. Опять же существуют различия между тем, как работают два аромата SQl. Я не использовал свой sql, поэтому я не уверен, что некоторые из общих точек отказа. Пока вы на нем, вы можете захотеть задать новые запросы и посмотреть, можно ли их оптимизировать. Оптимизация также варьируется от базы данных к базе данных, и пока вы ее используете, вероятно, есть некоторые плохо выполняемые запросы прямо сейчас, которые вы можете исправить как часть миграции.

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

Не забывайте о запланированных заданиях, они должны быть проверены и воссозданы в myslq.

Вы производите импорт любых данных по регулярному расписанию? Весь импорт должен быть переписан.

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

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

Answer 2

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

Answer 3

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

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

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

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

В настоящее время я просматриваю основную базу данных нашего приложения от MySQL 4.1 до 5, что намного меньше, но это будет очень и очень большая задача.