Богартинг уровня доступа к данным

Ситуация: dba является сторонним подрядчиком, который хранит весь код DAL в TFS. Было бы неплохо, как разработчик внешнего интерфейса, иметь возможность добавлять столбцы, настраивать процессы и все такое, не полагаясь на то, что этот чувак ответит на ваши письма, чтобы выполнить свою работу.

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

Мартин Фаулер и Прамод Садалаж написали отличную статью на эту тему.

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

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

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

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

Если он собирается быть единственным привратником, ему нужно либо иметь фиксированную спецификацию, либо быть в состоянии «продать» свое видение остальным разработчикам.

Существует серьезная проблема, которая заменяет любую другую проблему:

1. Почему подрядчик всегда проверяет код?

Почему ему разрешено это делать? Никто не должен проверять файл, если он не вносит правки. Там должна быть командная политика о проверках.

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

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

Таким образом, ни один человек / команда не может блокировать таким образом.

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

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

Просто, если вы этого еще не сделали, у вас должно быть 3 среды:

• Среда разработки
• QA Environment
• Производственная среда

Среда разработки должна администрироваться вашими разработчиками.

Вы также можете добавить RC-среду.

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

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

Это вопрос управления, а не только технический.

Безусловно, существуют веские причины, по которым администратор базы данных (независимо от того, находится ли он на месте или вне офиса, подрядчик или сотрудник), не позволяет разработчикам вносить какие-либо изменения в базу данных.

Однако основная проблема, которую вы определили, связана с доступностью. Ваш менеджер знает, что время / деньги потрачены впустую, ожидая этого человека? Если нет, вы можете рассказать, как все сидят.