Как справиться с эволюцией схемы?
В настоящее время мы используем обработанный вручную SQL в объектах доступа к данным и множестве хранимых процедур и триггеров, которые составляют около 20 тысяч строк кода. Мы обнаруживаем, что простые изменения требуют нескольких дней работы на исправление, что приводит к смещению сроков.
Изменения включают модификации таблиц для работы с дополнительными данными, общий рефакторинг схемы на основе отчетов QA / пользователей и т. д. Это очень активная система, которая строится для замены чего-то старого и медленного.
Мы рассмотрели доступные решения PHP ORM, чтобы попытаться ограничить влияние этих изменений, но они были слишком медленными, чтобы справиться с нашей схемой; «Простые» результаты sql возвращались на порядки дольше, чем наши пользовательские запросы, и из-за чего просмотры страниц занимали ~ 0,5 секунды, чтобы занять более 20 секунд.
Какие передовые практики / стратегии я мог бы изучить, чтобы справиться с эволюцией схемы с реляционными базами данных в общем контексте?
Редактировать: забыл упомянуть о триггерах; у нас есть много данных, которые зависят от каскадных изменений, например. изменение цены здесь для этого пользователя обновляет цену там для пользователя который и т. д.
Ответы 5
Я бы посоветовал избавиться от хранимых процедур и вместо этого использовать встроенный SQL, возможно, сохраненный в файлах text / xml. Я считаю, что SProcs гораздо более утомительны и требуют много времени на обслуживание. После создания плана запроса (при первом выполнении запроса) вы заметите незначительную разницу в производительности. Кроме того, вы сможете управлять версиями всех сценариев БД ...
Я поддержал, но SQL в файлах XML? "<SELECT> SELECT </SELECT> <STAR> * </STAR> <FROM> FROM </FROM> ..."?
Нет .. скорее: <Query Name = "GetUserDetails> выберите пользователя из числа пользователей, где ... </Query>
Не входит в основной пост; наши сохраненные процессы уже находятся в svn - мы сначала кодируем их в txt файлах перед запуском в db. Большая часть все, которая у нас есть, находится под контролем версий. В таком случае, как бы вы справились с триггерами?
Я предлагаю использовать стратегию непрерывная (или хотя бы ночная) сборка. Восстанавливайте базу данных при каждой регистрации или хотя бы раз в день. Также раз в день запускайте модульные тесты для проверки каждого бита кода, будь то хранимая процедура, триггер или уровень доступа к данным.
Написание сохраненных процедур требует больших затрат, но это позволит сразу же выявить сбои. Как только вы узнаете, где находится разрыв, вы сможете его исправить.
Мне было бы интересно услышать об опыте других людей с применением этой стратегии к изменениям базы данных.
Мы используем Корпоративный архитектор для наших определений БД. Мы включаем хранимые процедуры, триггеры и все определения таблиц, определенные в UML. Программа обладает тремя замечательными особенностями:
- Импортируйте диаграммы UML из соединения ODBC.
- Сгенерировать SQL-скрипты (DDL) для всей БД сразу
- Создание настраиваемой шаблонной документации для вашей БД.
За 10 с лишним лет работы в качестве разработчика я никогда не был так впечатлен ни одним другим инструментом. EA поддерживает Oracle, MySQL, SQL Server (несколько версий), PostGreSQL, Interbase, DB2 и Access одним махом. Каждый раз, когда у меня возникали проблемы, их форумы быстро отвечали на мои проблемы. Настоятельно рекомендуется!!
Когда поступают изменения в БД, мы вносим их в EA, генерируем SQL и проверяем его в нашем контроле версий (svn). Мы используем Hudson для сборки, и он автоматически создает базу данных из сценариев, когда видит, что вы изменили зарегистрированный sql.
Вы можете проверить эту книгу на Рефакторинг баз данных: эволюционный дизайн баз данных.
Вот мои предложения:
- Постарайтесь избавиться от наименее используемого функционала. Подвергайте сомнению функции, которые не используются постоянно. Каждая функция в приложении связана с несколькими уровнями затрат (обслуживание, поддержка, регрессионное тестирование, сложность кода и т. д.).
- Держитесь подальше от хранимых процедур, если нет абсолютно никакого способа сделать это эффективно и масштабируемым образом в коде.
- Постепенно вводите решение ORM (используя рефакторинг для перехода от JDBC к ORM), чтобы уменьшить объем кода и сложность кода в операциях CRUD.
- Создавайте функциональные, интеграционные и модульные тесты по мере исправления ошибки и включайте эти тесты в систему непрерывной интеграции. Максимально автоматизируйте регрессионное тестирование, чтобы выявлять проблемы, как только они возникают при регистрации.
- В общем, всякий раз, когда вы исправляете ошибку, используйте эту возможность для рефакторинга, чтобы отделить реализации / модули кода.
Если у вас есть вопросы о проблемах миграции базы данных, это может помочь: http://shashivelur.com/blog/2008/07/hibernate-db-migration/
Не могли бы вы привести пример изменения, на внедрение которого уходит много времени?