Стратегии для решения постоянно меняющихся требований к схемам MySQL?

Question

Я использую Hibernate EntityManager и Hibernate Annotations для ORM в очень ранней стадии проекта. Проект должен быть запущен в ближайшее время, но спецификации постоянно меняются, и я обеспокоен тем, что система будет запущена и будут собраны живые данные, а затем спецификации снова изменятся, и я буду в ситуации, когда мне нужно изменить схема базы данных.

Как я могу настроить вещи, чтобы минимизировать влияние этого? Существуют ли проекты с открытым исходным кодом, которые имеют дело с этим видом миграции? Может ли Hibernate сделать это автоматически (без очистки базы данных)?

Ваш совет очень ценится.

Answer 1

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

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

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

Answer 2

Hibernate может обновить модель объекта базы данных с данными в базе данных.Сделайте это и напишите код миграции в Java, который устанавливает или удаляет отношения данных.

Это работает, и мы сделали это несколько раз.Но, конечно, попробуйте следовать гибкому процессу разработки;сначала сделайте то, что вы знаете, затем пересмотрите требования - разборки и т. д.

Answer 3

Ни одна система не может автоматически создавать сценарии миграции данных только из оригинальной и окончательной схемы.Просто недостаточно информации.

Рассмотрим, например, новый столбец.Должно ли оно просто содержать значение по умолчанию?Или значение, рассчитанное по другим полям / таблицам.

Существует хорошая книга о рефакторинге баз данных: http://www.amazon.com/Refactoring-Databases-Evolutionary-Addison-Wesley-Signature/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1300140045&sr=8-1

Но инструментальная поддержка такого рода вещей практически отсутствует.

Я думаю, что лучшее, что вы можете сделать заранее:

• Не позволяйте никому получать доступ к базе данных, кроме вашего приложения
• Если что-то еще обязательно должно иметь прямой доступ к БД, дать ему отдельную точку зрения специально для этой цели.Это позволяет вам изменить структуру таблицы, сохранив хотя бы структуру того, что видят другие системы.
• Имеет массу тестов.Я только что опубликовал статью, которая (с предстоящей 2-й и 3-й частью) может немного помочь с этим: http://blog.schauderhaft.de/2011/03/13/testing-databases-with-junit-and-hibernate-part-1-one-to-rule-them/

Answer 4

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