Миграция с MySQL на произвольный, совместимый со стандартами сервер SQL2003

Question

Существует ли заклинание mysqldump или аналогичного инструмента, который будет создавать фрагмент кода SQL2003 для создания и заполнения тех же баз данных в произвольной СУБД, совместимой с SQL2003?

(Я сейчас пытаюсь это MonetDB)

Answer 1

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

С другой стороны, операторы DML довольно переносимы. Поэтому я предлагаю:

• Дамп базы данных без каких-либо данных (mysqldump --no-data) для получения схемы
• Внесите необходимые изменения, чтобы загрузить схему в другую БД - это нужно сделать вручную (но возможен некоторый поиск / замена)
• Сбросить данные с расширенными вставками и без создания таблицы (--extended-insert = 0 --no-create-info)
• Запустите полученный скрипт для другой БД.

Это должно делать то, что вы хотите.

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

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

Answer 2

Это довольно сложно. Если у вас нет очень простой структуры БД с ванильными типами (varchar, integer и т. Д.), Вы, вероятно, получите лучшие результаты, написав инструмент миграции. В таком языке, как Perl (через DBI), это довольно просто. Программа в основном представляет собой цикл эха, который читает из одной базы данных и вставляет в другую. Есть примеры такого рода кода, о котором Google знает.

Помимо очевидной проблемы перемещения данных, есть более тонкая проблема того, как представлены некоторые типы данных. Например, поле даты и времени MS SQL не имеет тот же формат, что и поле MySQL. Другие типы данных, такие как BLOB, могут иметь разную емкость в одной RDBM, чем в другой. Перед переносом убедитесь, что вы хорошо понимаете определения типов данных целевой системы БД.

Последняя проблема, конечно, заключается в том, чтобы заставить операторы уровня приложения работать с новой системой. В моей работе это самая сложная часть. Математика дат особенно специфична для БД, а раздражающие вещи, такие как правила цитирования, являются постоянным источником раздражения.

Удачи в вашем проекте.

Answer 3

Параметр генерирования сценария, вероятно, самый простой способ. Вам, несомненно, придется выполнить поиск / замену для нескольких типов данных.

Answer 4

Из SQL Server 2000 или 2005 вы можете создавать сценарии для ваших объектов, но я не уверен, насколько хорошо они будут передаваться в другие СУБД.