Использование общей базы данных для совместной разработки

Question

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

Answer 1

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

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

Для превосходного руководства по теории и практике обработки определения базы данных как другой части кода проекта и координации изменений и рефакторингов см. Рефакторинг баз данных: эволюционный дизайн баз данных Скотта В. Эмблера и Прамода Садалажа.

Answer 2

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

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

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

Answer 3

Мы разделяем одну базу данных со всеми нашими разработчиками (20 с лишним), но мы структурировали ее так, чтобы у каждого были свои таблицы.

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

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

Answer 4

Наличие одной точки отказа - это не хорошо, не так ли?

Answer 5

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

То, что работает для меня, может не сработать для вас. Иди со своей интуицией.

Answer 6

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

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