Одна БД на разработчика или нет?

Question

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

Answer 1

Мне нравится компромиссное решение (все разработчики совместно используют инфраструктуру, и если кому-то нужно протестировать изменения схемы, они создают свой собственный временный экземпляр БД (может быть, один просто сидит там для этой цели?), Пока они не будут рады совершить новая схема управления исходным кодом.)

Answer 2

Я работал в обоих типах сред разработки. Лично я предпочитаю иметь свой собственный сервер БД / приложений. Однако могут быть некоторые преимущества использования общей инфраструктуры для разработки.

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

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

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

У вас есть вся схема (и тестовые данные) в системе контроля версий, верно? Право ???

Answer 3

В моей компании мы склонны копировать всю БД при работе над нетривиальными новыми функциями. Причина в том, что дисковое пространство дешево, а случайная потеря данных (даже если это тестовые данные) - нет.

Answer 4

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

Answer 5

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

Answer 6

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

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

В MySQL и Sybase / MS SQLServer каждый механизм базы данных может поддерживать несколько баз данных. Каждая база данных (обычно) полностью независима от другой базы данных. Таким образом, вы можете иметь один экземпляр ядра СУБД и предоставить каждому разработчику свое пространство базы данных, чтобы он делал все, что хотел. единственная проблема заключается в том, что если разработчики используют базу данных tempdb - там могут быть столкновения (я думаю - это вам нужно будет найти). Только будьте осторожны, чтобы кросс-запросы к базе данных с фиксированными именами не использовались.

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

Answer 7

Мне нравится идея использования локальной версии, когда разработчик должен быть изолированным - разработка изменения схемы, тестирование производительности, настройка конкретных сценариев и т. Д. *

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

Answer 8

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

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

Answer 9

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