Дни, когда среды баз данных должны быть скудными, давно прошли. Я пишу это сообщение на XW9300 с дисками SCSI 5x15k. Эта машина будет выполнять существенную работу ETL в течение довольно разумного периода времени и (в середине 2007 года) обойдется мне в £ 1700 на ebay, включая диски. С точки зрения разработчика, особенно в проектах, ориентированных на базы данных, таких как хранилище данных, грань между разработчиком и администратором базы данных довольно размыта. Когда я пишу это, я создаю инфраструктуру управления разделами для хранилища данных SQL Server 2005.
Разработчики должны иметь одну или несколько собственных баз данных для разработки (IMO) по следующим причинам:
Требуется, чтобы люди хранили хранимые процедуры, сценарии исправлений и файлы определения схемы в системе контроля версий. Применение исправлений может быть автоматизировано в довольно большой степени. Есть даже такие инструменты, как Redgate SQL Compare Pro , которые делают большую часть тяжелой работы для этого.
Поощряет архитектуру приложения, которая облегчает управление конфигурацией и ее развертывание, поскольку людям приходится развертывать на своих собственных рабочих станциях. Многие морщины развертывания будут рассортированы задолго до того, как они попадут в производство, или люди даже поймут, что могли пойти не так.
Позволяет разработчикам не спешить с работой друг друга. На чем-то вроде хранилища данных, где люди работают с ETL-кодом, это еще большая победа.
Это поощряет определенную степень ответственности, поскольку разработчики должны изучать основы администрирования баз данных. Это также устраняет множество требований к персоналу оперативной поддержки и некоторым разработчикам. ops friction.
Если у вас есть собственная база данных, у вас нет привратников, препятствующих экспериментам или другим работам над ней. Политика в отношении управления «серверами» исчезает, поскольку «серверов» не существует.
Это выигрыш в производительности в любой среде со значительной бюрократией.
Для небольших объемов данных обычный компьютер достаточно быстр для этого. Редакции для разработчиков или лицензирование доступны для большинства, если не для всех систем управления базами данных, и будут работать на настольной операционной системе. Если вы работаете с Linux или Unix, это еще меньше проблем. Для больших объемов данных, вплоть до большинства приложений MIS, рабочую станцию, такую как HP XW9400 или Lenovo D10 , можно оснастить 5 дисками по 15 КБ, что обойдется дешевле, чем многие другие. профессиональный разработка оснастка . (Да, я знаю, что это двойная лицензия, но коммерческая лицензия на всю платформу для QT стоит около 4000 фунтов стерлингов за место).
Такая машина будет запускать процесс ETL с 10 до 100 миллионов строк быстрее, чем вы думаете.
Это облегчает настройку более чем одной среды для тестирования дыма или примирения. Поскольку у вас есть полный контроль над машиной, у вас есть достаточно возможностей для макетирования условий в производственной среде. Например, однажды я сделал простой эмулятор для Control-M , просто загрузив некоторые из его сценариев времени выполнения.
Если у вас есть такой уровень контроля и прозрачности в отношении среды, вы можете создать довольно надежно протестированный процесс развертывания, который очень многое делает для устранения возможностей для выявления в производственном развертывании.
Я видел небольшие команды, работающие с 14 средами, и у меня было 7 активных одновременно на рабочей станции. На тяжелой работе с базой данных, такой как ETL, где вы работаете с целыми таблицами, работа в среде с одним разработчиком - это трата времени или потеря времени на яичные скорлупы.
Кроме того, вы можете использовать однопользовательские лицензии на разработку для платформ баз данных, что может сэкономить вам стоимость рабочих станций только при лицензировании баз данных. Большинство лицензий для разработчиков (например, Microsoft и OTN - пара примеров, с которыми я знаком) позволяют использовать систему на одной рабочей станции бесплатно для одного разработчика или по номинальной цене.
С другой стороны, условия лицензирования на совместно используемых серверах разработки часто бывают несколько неясными, и я видел, как поставщики неоднократно пытались заставить клиентов отказаться от лицензирования на серверах разработчиков.