Как вы управляете базами данных во время разработки?

Ответ 1

Вы можете найти мой вопрос Как создать свою базу данных из источника управления.

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

Часто, более эффективно предоставлять отдельным разработчикам собственную изолированную среду, в которой они могут выполнять разработку и модульное тестирование, не затрагивая других разработчиков или тестеров. Однако это не панацея, потому что теперь вам необходимо обеспечить механизм, позволяющий синхронизировать эти несколько отдельных сред друг с другом с течением времени. Вы должны убедиться, что разработчики имеют разумный способ выбора друг друга (как данных, схемы, так и кода). Это не так просто. Хорошая практика СКМ может помочь, но для этого требуется значительный уровень сотрудничества и координации. Не только это, но предоставление каждому разработчику собственной копии всей среды может привести к затратам на хранение и дополнительному ресурсу DBA, чтобы помочь в управлении и надзоре за этими средами.

Вот некоторые идеи для вас:

• Создайте общую общедоступную "среду" (она может быть электронной), где разработчики могут легко видеть, какие среды доступны и кто их использует.
• Определите отдельное лицо или группу для собственных ресурсов базы данных. Они отвечают за отслеживание окружения и помогают разрешать конфликтующие потребности разных групп (разработчиков, тестеров и т.д.).
• Если позволяют время и бюджеты, подумайте о создании среды песочницы для всех ваших разработчиков.
• Если вы этого еще не делаете, подумайте о разделении "игровых зон" разработчика, от среды интеграции, тестирования и приемочного тестирования.
• Убедитесь, что вы контролируете важнейшие объекты базы данных, особенно те, которые часто меняются, как триггеры, хранимые процедуры и представления. Вы не хотите терять работу, если кто-то перезаписывает какие-то изменения.

Ответ 2

Мы используем локальные базы данных разработчиков и одну базовую базу данных для тестирования интеграции. Мы храним скрипты создания в SCM. Один разработчик отвечает за обновление сценариев SQL на основе схемы "золотой мастер". Разработчик может вносить изменения по мере необходимости в свою локальную базу данных, заполняя при необходимости данные из базы данных интеграции, используя процесс импорта или генерируя данные с помощью инструмента (Red Gate Data Generator, в нашем случае). При необходимости разработчики уничтожают свою локальную копию и могут обновляться после создания script и данных интеграции по мере необходимости. Обычно базы данных используются только для тестирования интеграции, и мы издеваемся над ними для модульных тестов, поэтому минимизируется объем работы, поддерживающей синхронизацию.

Ответ 3

Я рекомендую вам взглянуть на взгляды Скотта Аллена по этому вопросу. Он написал серию блогов, которые, на мой взгляд, превосходны. Три правила работы с базами данных, Базовый уровень, Изменить сценарии, Представления, сохраненные procs и т.д., Ветвление и слияние.

Я использую эти рекомендации более или менее, с личными изменениями, и они работают.

Ответ 4

В прошлом я рассматривал это несколько способов.

Один из них - это репозиторий SQL Script, который создает и заполняет базу данных. Это совсем не плохой вариант и может содержать все в синхронизации (даже если вы не используете этот метод, вы все равно должны поддерживать эти сценарии, чтобы ваша БД находилась в Source Control).

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

Ответ 5

У нас есть инструмент для обслуживания базы данных, который мы используем, который создает/обновляет наши таблицы и наши процессы. у нас есть сервер с самой современной базой данных, заполненной данными.

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

Если/когда мы добавляем столбцы/таблицы/procs, мы обновляем инструмент dbMaintenance, который хранится в исходном элементе управления.

иногда, его боль, но она работает достаточно хорошо.

Ответ 6

Если вы используете ORM, например nHibernate, создайте script, которые генерируют как схему, так и данные в базе данных LOCAL для разработчиков.

Улучшите, чтобы script во время разработки включал типичные данные.

Тестирование промежуточной базы данных перед развертыванием.

Мы реплицируем производственную базу данных в базу данных UAT для конечных пользователей. Эта база данных недоступна разработчикам.

Требуется меньше нескольких секунд, чтобы удалить все таблицы, создать их снова и ввести тестовые данные.

Если вы используете ORM, который генерирует схему, вам не нужно поддерживать создание script.

Ответ 7

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

Поскольку у нас была эта информация в самом коде, и поскольку у нас были подключаемые адаптеры SQL, было тривиально заставить этот код работать с базой данных в памяти (мы использовали HSQL). Следовательно, мы выполнили большую часть наших фактических разработок и тестирования производительности с "настоящими" локальными серверами (Oracle или SQL Server), но все модульные тесты и другие автоматизированные задачи с конкретными конкретными операционными базами данных.

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

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

Ответ 8

Как насчет этого подхода:

Поддерживайте отдельное репо для "чистого db". Репо будет представлять собой файл sql с таблицами create/inserts и т.д.

Использование Rails (я уверен, что можно было бы адаптировать для любого git repo), поддерживать "чистый db" в качестве подмодуля в приложении. Напишите script (возможно, задача rake), которая запрашивает локальный dev db с инструкциями SQL.

Чтобы очистить локальную базу данных (и заменить ее новыми данными):

git submodule init
git submodule update

затем

rake dev_db:update ......... (or something like that!)

Ответ 9

Я сделал одну из двух вещей. В обоих случаях разработчики, работающие над кодом, который может конфликтовать с другими, запускают собственную базу данных локально или получают отдельный экземпляр на сервере базы данных dev.

• Как и в случае с @tvanfosson, вы сохраняете набор SQL-скриптов, которые могут создавать базу данных с нуля, или

• В четко определенном, регулярном порядке все базы данных разработчиков заменяются копией производственных данных или сокращенной/деидентифицированной копией продукции в зависимости от того, какие данные мы используем.

Ответ 10

Я согласен со всем, что сказал в своем ответе Л.Бушкин. Если вы используете SQL Server, у нас есть решение в Red Gate, которое должно позволить вам легко обмениваться изменениями между несколькими средами разработки.

http://www.red-gate.com/products/sql_source_control/index.htm

Если есть проблемы с хранением, которые затрудняют работу вашего DBA с несколькими средами разработки, Red Gate имеет решение для этого. С технологией Red Gate HyperBac вы можете создавать виртуальные базы данных для каждого разработчика. Они выглядят точно так же, как обычная база данных, но на заднем плане общие данные распределяются между различными базами данных. Это позволяет разработчикам иметь свои собственные базы данных, не занимая нецелесообразного объема пространства на вашем SQL Server.