Управление моей базой данных в Source Control

Question

Поскольку я работаю с новым проектом базы данных (в рамках VS2008) и поскольку я никогда не разрабатывал базу данных с нуля, я сразу же начал изучать, как управлять базой данных в системе контроля версий (в данном случае, Subversion).

Я нашел некоторую информацию о SO, включая этот пост: Синхронизация баз данных разработки в нескольких средах . В одном из ответов, в частности , указывалось на несколько ссылок, каждая из которых содержала хорошую и полезную информацию.

Я читал серию сообщений К. Скотта Аллена, которые описывают, как он управляет изменением базы данных. Из моего прочтения (и прошу прощения за глупость моего вопроса) кажется, что сама база данных никогда не проверяется в хранилище. Скорее сценарии, которые могут построить базу данных, вместе с тестовыми данными (которые также заполняются из сценариев) проверяются в хранилище. В конечном итоге это означает, что когда разработчик тестирует свое приложение, эти сценарии, являющиеся частью процесса сборки, запускаются. Это гарантирует, что база данных обновлена, но также запускается локально с компьютера каждого разработчика.

Это имеет смысл для меня (если я действительно читаю это правильно). Однако, если я что-то упустил, я был бы признателен за исправление или дополнительные рекомендации. Кроме того, я хотел задать еще один вопрос - означает ли это, что я должен НЕ проверить файлы mdf или ldf , созданные из Visual Studio?

Спасибо за любую помощь и дополнительную информацию. Всегда ценится.

Answer 1

Это правильно, вы должны проверять в скриптах, а не сам файл базы данных.

Я не фанат построения из тестовых данных, если только сами данные не будут подражать размеру данных, которые есть у производства (или в случае новых баз данных, которые предполагается иметь). Зачем? потому что написание кода для таблицы с 100 записями не говорит вам, будет ли он выполняться своевременно, когда у вас есть 10 000 000 записей. У меня слишком много плохих дизайнерских решений, сделанных людьми, которые считают, что небольшой набор данных подходит для разработки.

Здесь мы не разрешаем разработчикам иметь отдельную базу данных на своем боксе (что обычно ограничивает размер базы данных, поскольку она не является сервером, подключенным к SAN), вместо этого они должны работать с базой данных dev, которая периодически обновляется из prod (а затем запускаются все новые сценарии разработки), чтобы сохранить данные нужного размера. Я думаю, что важно, чтобы ваша среда базы данных dev максимально соответствовала prod, включая конфигурацию оборудования, размер базы данных и т. Д. снят сразу, потому что это слишком сильно замедляет систему.

Спрыгиваю с моей мыльницы.

Answer 2

Это хорошая идея проверить в скриптах, так как контроль исходного кода лучше всего подходит для работы с текстовыми файлами, а не с двоичными файлами. Различия в файлах сценариев могут быть легко рассмотрены как часть остальных изменений кода, связанных с изменением базы данных. Помимо проверки сценариев базы данных, мы также проверяем моментальный снимок схемы базы данных. Этот снимок схемы базы данных позволяет нам проверить, соответствует ли производственная схема ожидаемой схеме для данной версии продукта. Кроме того, моментальный снимок схемы базы данных - это удобный способ поиска столбцов и таблиц в текстовом редакторе.

Answer 3

Я использую DataConstructor, но предвзято, потому что я его написал.

Answer 4

Вы можете использовать такой инструмент, как Liquibase для управления сценариями базы данных. Это действительно инфраструктура обновления базы данных, поэтому она будет отслеживать уже выполненные шаги, поэтому, например, когда вы хотите обновить производство, он выполняет только новые шаги.

Answer 5

Попробуйте SQL Examiner: Как сохранить вашу базу данных под контролем версий