Должны ли мы иметь отдельный экземпляр базы данных для каждого разработчика?

Question

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

1. Единая база данных для всех разработчиков.
2. Отдельная база данных для всех разработчиков.

Каковы плюсы и минусы каждого? И какой из них лучше?

Редактировать: Более одного разработчика должны обновить базу данных, и у нас уже есть SqlExpress 2005 на каждом компьютере разработчика.

Редактировать: Большинство из нас предлагают общую базу данных. Однако, если один из разработчиков изменил код и схему базы данных. Он не зафиксировал изменения кода, но изменения схемы были переданы в общую базу данных. Не нарушит ли он код других разработчиков.

Answer 1

Оба -

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

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

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

Answer 2

Общая база данных

• Simpler
• Меньше случаев "Это работает на моей машине".
• Интеграция сил
• Проблемы быстро обнаруживаются (быстро отказывают)

Индивидуальные базы данных

• Никогда не влияйте на других разработчиков, но это тоже плохо, при постоянной интеграции

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

У нас есть отдельные серверы приложений разработки (веб), но они совместно используют одну базу данных. Наши разработчики имеют возможность использовать свою собственную базу данных, поскольку они знают, как ее настроить, и будут делать это время от времени, но только временно. Для нас нормой является совместное использование базы данных.

Answer 3

Думаю, я бы добавил это, но почему бы не позволить каждому разработчику разместить свой собственный экземпляр SQL Server Developer на своих рабочих столах, а затем иметь общий сервер для каждой из других сред (разработки, QA и prod)? Я думаю, что даже базовый MSDN, который поставляется с Visual Studio Pro (если вы выберете его), включает в себя лицензию на SQL Server Developer.

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

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

Общая среда полностью необходима для тестирования - я бы не рекомендовал переходить с рабочего стола на рабочий. Но вы можете добавить так много, предоставив разработчикам 100% контроль над данной средой базы данных (включая изоляцию от других) с относительно небольшими затратами.

Answer 4

Зависит от ваших циклов разработки, тестирования и обслуживания. Также о размере и местонахождении команды разработчиков (и, конечно, организации). Если вы поддерживаете несколько версий базы данных, вам может потребоваться еще больше сред.

В реальном мире я нашел следующий подход весьма удовлетворительным:

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

Вот еще несколько пунктов:

Если два разработчика (две команды) работают над изменениями, которые могут повлиять друг на друга, они должны выполнить свои задачи независимо, а затем интегрировать / объединить и протестировать. Для этого гораздо лучше иметь отдельные среды разработки (если только они не должны работать вместе, и в этом случае я считаю их частью одной команды; тем не менее они могут работать над своими собственными копиями базы данных и совместно использовать ее при необходимости)

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

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

И все же было бы здорово, если бы вы могли обмениваться тестовыми примерами, поэтому возможность простого и быстрого сброса / восстановления базы данных является большим плюсом.

EDIT:
Все вышеперечисленное предполагает, что наличие копии на локальном компьютере всей системы для целей тестирования возможно (размер, производительность, лицензии и т. Д.).

Answer 5

Мы делаем оба:

Мы используем генерацию кода , где я нахожусь, и наша база данных также генерируется. Таким образом, у нас есть экземпляр на коробке каждого разработчика, где создается база данных. Затем мы используем созданные сценарии, чтобы применить изменения к центральной тестовой базе данных. Если все идет хорошо, мы применяем изменения к производственной базе данных во время выпуска.

Что хорошо в этом подходе, так это то, что когда наш «источник правды» возвращается в систему контроля версий, все изменения базы данных автоматически передаются другим разработчикам, когда они перезагружаются и восстанавливаются. У нас это хорошо работает.

Answer 6

Я бы выбрал решение № 1: Одна общая база данных для всех разработчиков.

Плюсы

1. дешевле для инфраструктуры;
2. Для обновления базы данных разработки требуется только один дамп;
3. Все разработчики используют одни и те же данные, поэтому они близко представляют производственную среду;

Против

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

Что касается решения № 2: одна независимая база данных для каждого из разработчиков;

Плюсы

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

Против

1. дороже для компании (инфраструктура, лицензии ...);
2. Умножение проблем, вызванных энергичной средой разработки изоляции (работает в среде devloper, не интегрировано);
3. Умножение дампов администратором базы данных той же копии из производственной среды.

Учитывая вышесказанное, я бы порекомендовал, в зависимости от размера вашей компании:

1. Одна база данных для разработки;
2. Одна база данных для тестирования интеграции;
3. Одна база данных для приемочных испытаний;
4. Один для разработки новых функций, который, возможно, потребует интеграционных тестов.

Если вашей компании не требуются интеграционные тесты, то примите приемочные тесты, этот шаг крайне важен перед началом производства.

Answer 7

С какой стати вам нужна отдельная база данных для всех разработчиков? Имеется одна общая база данных для всех, таким образом, структура таблиц является согласованной, и операторы sql также.

Answer 8

Самые большие проблемы с разработчиками, имеющими собственные базы данных:

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

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

Теперь сервер общей базы данных должен иметь то, что мы называем «чистой базой данных», местом, где люди могут создавать и тестировать изменения таблицы, поэтому, если они делают что-то, что может потребоваться, чтобы удалить и заново создать таблицу (что должно быть редким случаем !), они могут сначала протестировать процесс, скопировав таблицу в рабочую базу данных и запустив там процесс, а затем переключившись на реальную базу данных, когда они уверены, что она работает. Или мы часто копируем таблицу резервных копий в рабочую базу данных перед тестированием конкретного изменения, поэтому мы можем легко восстановить старые данные, если они испортились.

Я не вижу никаких преимуществ в использовании отдельных баз данных.

Answer 9

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

Answer 10

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

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