ther, весь код заливается в git или какую-либо иную систему контроля версий. Выбор зависит от желания разработчиков. Проект для git можно сделать через любую компарилку (инструмент для сравнения баз/проектов): Visual Studio - проект базы данных, сравнение базы с проектом, Redgate SQL Compare - сравнение базы с папочкой с заливкой в нее исходников. Возможно, есть ещё инструменты. Я пользовался этими двумя, предпочитал Redgate.
Основное правило работы с git: ветка master всегда должна совпадать с состоянием боевой базы - изменения напрямую в боевой базе не допускаются.
Разработчики либо совсем не имеют доступа на бой, либо имеют доступ только на чтение/просмотр описаний объектов.

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

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

Процесс разработки:
Разработчики под каждую задачу заводят веточку в git, в зависимости от сложности фичи, либо напрямую правят объекты базы в проекте, редактированием файликов, либо сначала накатывают проект на свою базу, разрабатывают в базе, потом через компарилку заливают изменения в проект, делают коммит.
Коммит отправляется на code review либо выбранному ответственному за его проведение (если есть старшие/младшие разработчики), либо случайному коллеге (если уровень разработчиков в целом близок).
Далее, при работе по gitflow или похожему процессу - создается релизная ветка, в нее включаются задачи, которые должны войти в релиз, коммиты этих веток сливаются в релизную, через средство автоматизации (в разных местах использовали TFS и Teamcity) собираются скрипты наката/отката релиза.
Релиз накатывается на тест, проходит функциональное тестирование (новая фича работает), накатывается на предпрод, проходит регрессионное тестирование (старые фичи не сломались), накатывается на прод силами DBA, либо через автоматический инструмент, типа Octopus Deploy.

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

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

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

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

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

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