MS SQL - миграция MySQL в устаревшем веб-приложении - PullRequest
1 голос
/ 15 октября 2008

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

Ответы [ 3 ]

1 голос
/ 15 октября 2008

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

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

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

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

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

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

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

0 голосов
/ 16 октября 2008

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

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

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

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

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

0 голосов
/ 15 октября 2008

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

...