Открыть список
Как стать автором
Обновить

Комментарии 19

Это означает, что для каждой модификации мы должны создать отдельный сценарий SQL с изменениями

Какая нафиг Best Practice? Как автогенерированный write only скрипт позволит отслеживать, какие обновления уже были накачены, а какие нет? Такое надо делать кодом.
Веселее всего когда приходится накатывать апгрейды на базу от версии, отстающей от нынешней на пару цифр, там такие замечательные баги вылезают, особенно в ORM.
Миграции в рельсах/django решают эти проблемы
«Best practice #6: версии базы данных должны храниться в самой базе данных»
Никто руками скрипты не накатывает. Для Java, к примеру, есть flyway
Что-то я не услышал волшебного слова «Миграция» в этом переводе. Откройте для себя новый замечательный инструмент, и вам не захочется переводить капитанские статьи. Сам перевод недурственен.
Мб немного не в тему, но всё же. Кто знает как подружить EF6+npgsql+Постгрес с миграциями? (.NET)
А что у вас не получилось? Действия те же самые, что и в случае с mssql, только в конструкторе класса Configuration нужно
SetSqlGenerator("Npgsql", new NpgsqlMigrationSqlGenerator());
Скорее всего в статье нет слова «миграция» потому, что в названии сайта есть слово «enterprise». А это значит, что к одной БД может быть подключено десятки (а в случае запущенной стадии энтерпрайза и сотни) приложений. В каком из них делать миграции?
В том, которое является основным стейкхолдером конкретного компонента БД.

Впрочем, паттерн «десятки и сотни приложений подключены к одной БД» в энтерпрайзе давно считают плохим, так что лучше стараться его избегать (я понимаю, что это мир розовых пони, но помечтать-то можно?).
Проблема именно в терминологии, или есть реальные отличия между инструментом «Миграции» и тем, что предлагается в статье?
То что описывается в статье, на мой взгляд, и есть миграции. Это как написать статью о том как правильно вкручивать сотни шурупов не упоминая шуруповёрт.
Видимо предлагаемая в статье книга была написана до появления этого термина )
У меня тоже возникли именно такие подозрения ;).
Versioning — управление версиями.

Best practice #6: версии базы данных должны храниться в самой базе данных. Я, как правило, создаю отдельную таблицу с названием «Settings» и храню версию там. Не используйте сложные обозначения типа «x.y.z» для номеров версий, просто используйте целое число.

У нас в mysql версия таблицы прописывается в комментарии к таблице.
Versioning — управление версиями.

Спасибо за уточнение. Поправил.
Посмотрите на Liquibase.
Там есть все что вы описали + много другого полезного.
А еще бы кто написал как сохранять предыдущую версию базы работоспособной, например, для поддержки API предыдущей версии.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.