Комментарии 16
хранение бекапов базы данных в VCS — это надо додуматься. А тем более применение к ним diff и др. подобных инструментов.
Назначение бэкапов баз данных — просто храниться. Для любой обработки или анализа бэкап должен быть восстановлен (возможно в новую базу или копию).
«Обычные» ERP это 1С v8, например. У них размер бэкапов в сотни гигабайт. Никакая обработка кроме как средствами самого SQL-сервера на таких объёмах технически невозможна.
Назначение бэкапов баз данных — просто храниться. Для любой обработки или анализа бэкап должен быть восстановлен (возможно в новую базу или копию).
«Обычные» ERP это 1С v8, например. У них размер бэкапов в сотни гигабайт. Никакая обработка кроме как средствами самого SQL-сервера на таких объёмах технически невозможна.
Так вроде и автор говорит — не храните бэкапы в CVS. Только вы, по-моему, путаете: большие бэкапы, это на рабочих базах. А тут идет речь о процессе хранения данных в процессе разработки, где нет пользовательских данных.
А конфигурации? :) Например настройки форм, пользователи, тестовые данные. Можно же частично заливать, вытягивать. Очень полезно видеть что когда и как было раньше. Конфигурации то начальные как-то создаются, и хорошо, если это не blob, а читаемый XML.
Да и речь то не о том как хранить бэкап БД в VCS, а о том как накатывать обновления (в том числе частичные), предзагружать начальную конфигурацию и т.п. А где хранить саму БД — вопрос религии, он лежит вне этой темы.
Да и речь то не о том как хранить бэкап БД в VCS, а о том как накатывать обновления (в том числе частичные), предзагружать начальную конфигурацию и т.п. А где хранить саму БД — вопрос религии, он лежит вне этой темы.
Вы путаете бэкапы, то есть архивные копии, с дампами, т.е. копией содержимого.
У автора статья задача хранить данные, которые должны попасть в БД. Это нормальное требование. И хранить их надо в версионнике, потому что это нормальный артефакт разработки (читайте Continuous Delivery, там описано хранение вплоть до образов виртуальных машин). А дальше автор собственно и выбирает, в каком именно виде это (данные) хранить в VCS.
У автора статья задача хранить данные, которые должны попасть в БД. Это нормальное требование. И хранить их надо в версионнике, потому что это нормальный артефакт разработки (читайте Continuous Delivery, там описано хранение вплоть до образов виртуальных машин). А дальше автор собственно и выбирает, в каком именно виде это (данные) хранить в VCS.
А вы не смотрели в сторону Liquidbase?
A .NET Port of Liquibase is in the very early stages of forming. If you would like more information or to help out, visit the .Net Port page
А зачем вам .NET port? У вас какая-то CI система которая работает только с .Net?
>>Такие связи приходится принудительно разрывать
Пробовали смотреть в сторону отложенных(deffered) ограничений целостности? Которые проверяются не при непосредственной вставки в таблицу, а при фиксации транзакции. Оракл — умеет. PG, слышал, — тоже. MS — низна
Пробовали смотреть в сторону отложенных(deffered) ограничений целостности? Которые проверяются не при непосредственной вставки в таблицу, а при фиксации транзакции. Оракл — умеет. PG, слышал, — тоже. MS — низна
У нормальных ERP-платформ есть средства сериализации объектов и данных вместе с метаданными, что позволяет их загружать без каких-либо усилий. При этом не нужно никаких сортировок, удаления ключей и прочего шаманства.
В пресловутой 1С 8.х — это планы обмена.
В пресловутой 1С 8.х — это планы обмена.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Загрузка и хранение данных в приложении со сложной структурой БД