Comments 19
Это означает, что для каждой модификации мы должны создать отдельный сценарий SQL с изменениями
Какая нафиг Best Practice? Как автогенерированный write only скрипт позволит отслеживать, какие обновления уже были накачены, а какие нет? Такое надо делать кодом.
Веселее всего когда приходится накатывать апгрейды на базу от версии, отстающей от нынешней на пару цифр, там такие замечательные баги вылезают, особенно в ORM.
Что-то я не услышал волшебного слова «Миграция» в этом переводе. Откройте для себя новый замечательный инструмент, и вам не захочется переводить капитанские статьи. Сам перевод недурственен.
Мб немного не в тему, но всё же. Кто знает как подружить EF6+npgsql+Постгрес с миграциями? (.NET)
UFO just landed and posted this here
Проблема именно в терминологии, или есть реальные отличия между инструментом «Миграции» и тем, что предлагается в статье?
Versioning — управление версиями.
У нас в mysql версия таблицы прописывается в комментарии к таблице.
Best practice #6: версии базы данных должны храниться в самой базе данных. Я, как правило, создаю отдельную таблицу с названием «Settings» и храню версию там. Не используйте сложные обозначения типа «x.y.z» для номеров версий, просто используйте целое число.
У нас в mysql версия таблицы прописывается в комментарии к таблице.
Посмотрите на Liquibase.
Там есть все что вы описали + много другого полезного.
Там есть все что вы описали + много другого полезного.
Best practice #0: использовать Liquibase.
А еще бы кто написал как сохранять предыдущую версию базы работоспособной, например, для поддержки API предыдущей версии.
Sign up to leave a comment.
Лучшие подходы к управлению версиями баз данных