我们维护了一组更改脚本，当我们的 Web 应用程序发布时，这些脚本必须在数据库上运行。我们浪费了很多时间并且经历了一些难以保持更新的过程，但是，我们的 DBA 喜欢（正确地）调整实时系统上的存储过程和模式以保持系统性能。
每隔一段时间，我们就必须将补丁重新定位到当前模式和存储过程，然而，检测哪些更改可能会发生冲突并找出我们可能破坏哪些 DBA 更改是非常困难的。
其他人如何管理对实时数据库的更改需求以应对待处理的更改？
我们可以采取哪些流程来使此流程更加顺畅？
存储、管理我们的模式和应用我们/他的变更集的最佳方式是什么？
提前致谢。
DBA 不应该只在 prod 上调整 procs。他们还应该使用源代码控制并将更改放在其他环境中，以便其他进行更改的人知道它们。
对数据库模式脚本进行任何和所有 DDL 更改，然后将其存储在您的源代码控制中。特别是您的 DBA 所做的更改 - 我建议在将您的基本架构和存储过程检查到您的源代码控制之前，由数据库开发人员和 DBA 检查（HLGEM 表示支持）。进入 prod 应该在应用之前编写脚本并获得批准（即，如果 DBA 发现需要更改的内容，让 DBA 打开缺陷并通过该过程进行处理）。
锁定所有此类 DDL 更改，远离您的开发人员。编写 Java 和 C# 的聪明人应该与您的团队数据库“专家”就如何最好地完成数据库方面的设计目标和需求进行沟通。
将生产调整限制在那些高度依赖情况的情况下，例如，许多 IT 商店都有一个 DBA，他将根据您的应用程序提供的数据库部署脚本定义物理存储设置，这通常是可以的。带有您的应用程序的向导可以帮助经验不足的人，以及设置和基本调整的前 10 项建议列表，这将大有帮助。