Миграция MS SQL - MySQL в устаревшем веб-приложении

Question

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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