Stategies для преодоления эволюции схемы? [закрытый]
Почему бы вам просто не «жестко закодировать» это имя класса? Это общепринятый подход, когда дело доходит до регистраторов
public abstract class AbstractDAProcedureMenuReceivedHandler<T extends AbstractDAProcedureMenuReceivedEvent> extends DaCommonEventHandler<T> {
private static final Logger logger = LoggerFactory.getLogger(AbstractDAProcedureMenuReceivedHandler.class);
...
}
, любое другое решение - быть честным излишним для этого
5 ответов
Вы могли бы хотеть к контролю эту книгу по Рефакторингу Баз данных: Эволюционное Проектирование баз данных.
Я предлагаю использовать непрерывное (или по крайней мере ночью) стратегия сборки.
Восстановите базу данных по каждой регистрации, или по крайней мере однажды в день.
Также однажды в день, выполненные модульные тесты, чтобы осуществить каждый бит кода, быть этим в сохраненном procedur, триггере или уровне доступа к данным.
Существует большая стоимость для записи сохраненного procs, но это сразу определит повреждения.
После того как Вы знаете, где повреждение, можно зафиксировать его.
Мне было бы интересно слышать, что опыт других людей с этой стратегией относился к изменениям базы данных.
Мы используем Архитектора Предприятия для наших определений DB. Мы включаем хранимые процедуры, триггеры и все определения таблицы, определенные в UML. Три блестящих функции программы:
- Импортируйте диаграммы UML из соединения ODBC.
- Генерируйте Сценарии SQL (DDL) для всего DB сразу
- Генерируйте Пользовательскую Шаблонную Документацию своего DB.
Я больше никогда не впечатлялся никаким другим инструментом в своих 10 + годы как разработчик. EA поддерживает Oracle, MySQL, SQL Server (несколько версий), PostGreSQL, Межоснова, DB2 и Доступ одним махом. Любое время у меня были проблемы, их форумы, ответило на мои проблемы быстро.Очень рекомендуем!!
Когда изменения DB входят, мы делаем затем в EA, генерируем SQL и проверяем его в нашем управлении версиями (svn). Мы используем Гудзон для создания, и это автосоздает базу данных из сценариев, когда это видит изменение зарегистрированного sql.
Мой совет состоял бы в том, чтобы избавиться от хранимых процедур и вместо этого использовать встроенный SQL, возможно, сохраняемый в тексте/XML-файлах. Я нахожу, что SProcs являются намного более раздражающими и трудоемкими для поддержания. После того как план запросов сгенерирован (в первый раз, когда запрос выполняется), Вы заметите незначительную разницу в производительности. Плюс Вы сможете к управлению версиями свои все сценарии DB...
Вот мои предложения:
- Попытайтесь избавиться от наименее используемой функциональности. Подвергните сомнению функции, которые не используются все время. Каждая функция в приложении имеет несколько уровней затрат, связанных с ним (поддержание, поддержка, регрессионное тестирование, сложность кода, и т.д.).
- Держитесь подальше от Хранимых процедур, если нет абсолютно никакого способа сделать это эффективно и масштабируемым способом в коде.
- Представляйте решение ORM постепенно (использующий осуществляющий рефакторинг для перемещения от JDBC до ORM) для сокращения объема кода и сложности кода в операциях CRUD
- Функциональная сборка, интеграция и модульные тесты как и когда Вы исправляете ошибку и включаете те тесты в к Непрерывной системе интеграции. Автоматизируйте свое регрессионное тестирование как можно больше для идентификации проблем, как только оно представлено регистрацией.
- В целом, каждый раз, когда Вы исправляете ошибку, используйте ту возможность осуществить рефакторинг для отделения модулей реализаций/кода.
Если Вы имеете, имеют вопросы о проблемах миграции Базы данных, это могло бы помочь: http://shashivelur.com/blog/2008/07/hibernate-db-migration/