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

Ответ 1

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

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

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

Конечно, нам нужны сценарии для изменений в базе данных, а ВСЕ - в Source Control.

Ответ 2

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

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

• Требует, чтобы люди хранили хранимые процедуры, сценарии исправления и файлы определения схемы в системе контроля версий. Применение исправлений может быть автоматизировано в довольно большой степени. Есть даже такие инструменты, как Redgate SQL Compare Pro, которые делают большую часть тяжелой работы для этого.

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

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

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

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

• Для небольших объемов данных обычный компьютер достаточно быстр для этого. Редакции для разработчиков или лицензирование доступны для большинства, если не для всех систем управления базами данных, и будут работать на настольной операционной системе. Если вы работаете с Linux или Unix, это еще меньше проблем. Для больших объемов данных, вплоть до большинства приложений MIS, такая рабочая станция, как HP XW9400 или Lenovo D10, может быть оснащена 5 дисками по 15 КБ, что обойдется дешевле, чем многие профессиональные инструменты разработки. (Да, я знаю, что это двойная лицензия, но коммерческая лицензия на все платформы для QT стоит около 4000 фунтов стерлингов за место). Такая машина будет запускать процесс ETL с 10 до 100 миллионов строк быстрее, чем вы думаете.

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

Ответ 5

Моя рекомендация состоит в том, чтобы иметь 2 уровня среды разработки:

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

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

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

Ответ 12

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

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

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

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

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

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

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

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

Ответ 16

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

Ответ 17

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

Ответ 18

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

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

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

Ответ 19

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