Что стандартный или лучший способ состоит в том, чтобы иметь дело с базой данных, переходящей с ответвлениями Мерзавца или Подвижным?
Это было большим вопросительным знаком на моем уме.
Я перемещаюсь в Подвижный или Мерзавца очень скоро для моего веб-программного обеспечения, и иногда мои ответвления требуют значительных изменений базы данных, которые не должны видеть другие ответвления. Это, я не могу всегда совместно использовать ту же базу данных для своих ответвлений.
Есть ли некоторый стандартный способ иметь дело с изменениями базы данных для того, чтобы перейти и клонироваться? Что Вы все делаете? Я использую MySQL.
4 ответа
У меня нет ответа, но я наткнулся на недавнюю статью, которая может быть актуальной: Почему ваша стратегия управления версиями базы данных - отстой и что с этим делать, Часть I
Использование инструмента изменения базы данных может быть действительно полезным. Я использовал Liquibase ( http://www.liquibase.org ) на работе, чтобы управлять контролем версий для базы данных. Я настоятельно рекомендую этот инструмент всем. Liquibase поддерживает наборы изменений с настраиваемыми сценариями отката. Однако это инструмент для управления схемой, а не фактическими данными. Я бы не стал использовать его для поддержания актуальности данных таблицы.
Тем не менее, я по-прежнему считаю, что лучше всего использовать Liquibase и разные схемы для разных исходных веток.
Для обработки клонирования ваша база данных должна быть многопользовательской.
При изменении схемы зафиксируйте изменения схемы для этой ветви как части репозитория.
Затем вы должны решить для каждой схемы, запускаете ли вы несколько табличных пространств в одной базе данных, нескольких базах данных и т. Д.? Затем зафиксируйте указатель на правильный как часть конфигурации установки в этой ветке.
Схема базы данных сама по себе является (записанной в) базой данных, структура которой более или менее определена INFORMATION_SCHEMA стандарта SQL.
Теперь, СУБД разработаны вполне сознательно, чтобы позволить только одно единственное значение базы данных в любой отдельный момент времени. А поскольку каталог сам по себе является "просто значением базы данных для базы данных INFORMATION_SCHEMA", системы SQL поддерживают, вполне сознательно, только одну единственную структуру базы данных в любой отдельный момент времени.