Управление моей базой данных в управлении исходным кодом

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

Я нашел некоторую информацию о Так, включая это сообщение: Хранение баз данных разработки в нескольких средах в синхронизации. Один из ответов в особенности указал на много ссылки, все из которых имели хорошую, полезную информацию.

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

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

Спасибо за любую справку и дополнительное понимание. Всегда ценившийся.

8
задан Community 23 May 2017 в 12:19
поделиться

4 ответа

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

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

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

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

6
ответ дан 5 December 2019 в 18:57
поделиться

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

1
ответ дан 5 December 2019 в 18:57
поделиться

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

2
ответ дан 5 December 2019 в 18:57
поделиться
0
ответ дан 5 December 2019 в 18:57
поделиться
Другие вопросы по тегам:

Похожие вопросы: