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

https://stackoverflow.com/questions/234580

04-07-2019
|

Вопрос

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

Решение

Если вы все совместно используете одну и ту же базу данных, у вас могут возникнуть некоторые проблемы, если кто-то внесет структурное изменение в базу данных и код не будет синхронизирован " Синхронизирован " с этим.

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

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

Конечно, нам требуются сценарии для внесения изменений в базу данных, и ВСЕ находится в системе контроля версий.

Другие советы

Времена, когда сред баз данных должно было быть недостаточно, давно прошли.Я пишу этот пост на XW9300 с 5x15k SCSI-дисками.Эта машина будет выполнять значительную работу ETL в течение достаточно разумного периода времени и (в середине 2007 года) обошлась мне на eBay примерно в 1700 фунтов стерлингов, включая диски.С точки зрения разработчика, особенно в проектах, ориентированных на базы данных, таких как хранилища данных, грань между разработчиком и администратором базы данных довольно размыта.Пока я пишу это, я создаю структуру управления разделами для хранилища данных SQL Server 2005.

Разработчикам следует иметь одну или несколько собственных баз данных разработки по (IMO) следующим причинам:

Требует, чтобы люди хранили хранимые процедуры, сценарии исправлений и файлы определений схемы в системе контроля версий.Применение патчей можно в значительной степени автоматизировать.Есть даже такие инструменты, как Redgate SQL Compare Pro которые делают большую часть тяжелой работы для этого.
Поощряет архитектуру приложений, которая упрощает управление конфигурацией и развертывание, поскольку людям приходится выполнять развертывание на своих собственных рабочих станциях.Многие проблемы с развертыванием будут устранены задолго до того, как они попадут в производство, или люди даже поймут, что они могли пойти не так.
Позволяет разработчикам не вмешиваться в работу друг друга.Для чего-то вроде хранилища данных, где люди работают с кодом ETL, это еще большая победа.
Это поощряет определенную степень ответственности, поскольку разработчикам приходится изучать основы администрирования баз данных.Это также устраняет многие требования к персоналу оперативной поддержки и некоторым специалистам по разработке.опс трение.
Если у вас есть собственная база данных, нет никаких привратников, мешающих экспериментам или другой работе с ней.Политика управления «серверами» исчезает, поскольку «серверов» нет.Это выигрыш в производительности в любой среде со значительной бюрократией.
Для небольших объемов данных для этого достаточно быстро обычного ПК.Редакции или лицензии для разработчиков доступны для большинства, если не для всех, систем управления базами данных и могут работать на настольных операционных системах.Если вы работаете с Linux или Unix, это еще не проблема.Для больших объемов данных, включая большинство приложений MIS, рабочая станция, подобная HP XW9400 или Леново Д10 можно оснастить 5 дисками по 15 тыс. дешевле, чем стоимость партии профессиональный разработка оснастка.(Да, я знаю, что это двойная лицензия, но коммерческая лицензия на все платформы для QT стоит около 4000 фунтов стерлингов за место).Такая машина будет запускать процесс ETL с 10–100 миллионами строк быстрее, чем вы думаете.
Это облегчает настройку нескольких сред для дымового тестирования или согласования.Поскольку вы имеете полный контроль над машиной, у вас есть достаточно возможностей для моделирования условий в производственной среде.Например, я однажды сделал простой эмулятор для Контроль-М просто подменив некоторые из своих сценариев выполнения.Там, где у вас есть такой уровень контроля и прозрачности среды, вы можете создать достаточно тщательно протестированный процесс развертывания, который во многом устраняет возможности для выявления виновников при производственном развертывании.

Я видел небольшие команды, работавшие с 14 средами, и одновременно на одной рабочей станции работало 7.При тяжелой работе с базами данных, такой как ETL, где вы работаете с целыми таблицами, работа в единой среде разработки — это пустая трата времени или трата времени на хождение по яичной скорлупе.

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

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

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

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

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

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

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

Так что ответ да и нет. :-) Дайте каждому разработчику собственную среду, если эту среду можно воспроизвести недорого.

Я рекомендую иметь 2 уровня среды разработки:

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

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

Этот вопрос намекает на то, что разработчику необходимо для выполнения его / ее работы. Конечно, должен быть предоставлен частный экземпляр БД. Не менее важно, чтобы я удостоверился в том, что БД - это тот же продукт / версия, что и та, которую вы собираетесь развернуть. Не разрабатывайте на MySQL 6.x и не развертывайте на MySQL 5.x. (Это касается и серверов приложений, и веб-серверов!)

Наличие базы данных разработчика не обязательно означает, что она должна быть размещена на вашем локальном компьютере. У вас может быть центральная машина СУБД, на которой расположены все базы данных разработчиков. Плюсы - это гарантия, которую вы разрабатываете против целевой БД. Меньшая нагрузка на устройства разработки, больше места / мощности для мощных IDE и серверов приложений. Минусы - это единственная точка отказа для всех разработчиков. (Сервер СУБД выходит из строя, никто не может работать.) Отсутствие возможностей разработки и администрирования СУБД. Разработчики не могут так легко экспериментировать с будущими выпусками БД или альтернативными вариантами БД для решения сложных задач.

Некоторые плюсы могут быть минусами и наоборот в зависимости от вашей организации и структуры. Может быть, вы не хотите, чтобы разработчики администрировали СУБД. Может быть, вы планируете поддерживать различные платформы БД. Решение сводится к вашей организации, а также к вашей целевой платформе. Если вы планируете использовать различные комбинации БД / ОС / сервера приложений, то каждый разработчик должен не только иметь свою собственную БД, но и работать в уникальной комбинации. (MySQL / Tomcat / OSX для одного DB2 / Jetty / Linux для другого Postegres / Geronimo / WinXP для третьего и т. Д. И т. Д.) Если вы настраиваете магазин типа ASP (Application Service Provider) на iSeries с другой стороны, то, конечно, вы Скорее всего, у вас будет центральный хост со всеми базами данных разработчика, но каждый разработчик должен иметь как минимум отдельный экземпляр базы данных, чтобы разрешить структурные изменения в схеме.

У меня есть экземпляр SQLServer Development Edition, установленный локально. У нас есть сервер QA DB, а также несколько производственных серверов. Все тестирование разработки и интеграции выполняется с использованием моего локального сервера (или локальных серверов других разработчиков). Новые выпуски размещаются на сервере QA. Каждый релиз после принятия заказчиком запускается в производство.

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

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

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

у вас есть большое количество разработчиков, нуждающихся в ресурсах (в нашем отделе их около 80)
каждому разработчику нужно несколько ресурсов (обычно я использую 4-5 разных баз данных каждый день)
актуальные данные важны (вы просто не можете обновить их достаточно быстро)

В этих случаях необходимы общие экземпляры и хорошее общение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одна БД на разработчика. Нет вопросов. Но на самом деле проблема заключается в том, как создать сценарий для целых баз данных, «контролировать данные» и создать их версию. Мое решение здесь: http://dbsourcetools.codeplex.com/ Повеселись. - Натан.

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow