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

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

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

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

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

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

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

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

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

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

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

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

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

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