管理DBA的生产更改/调整与dev的待定DB更改脚本的合并

Question

我们维护了一组必须在我们的Web应用程序发布时在数据库上运行的更改脚本。我们浪费了大量时间并且经历了一些难以保持这些更新但是，我们的DBA喜欢（正确地）调整实时系统上的存储过程和模式以维持系统性能。

我们经常需要将补丁重新绑定到当前架构和存储过程，但是，检测哪些更改可能会发生冲突并确定我们可能会破坏哪些DBA更改是非常困难的。

其他人如何根据待定更改管理实时数据库更改的需求？

我们可以采取哪些流程来使这一流程更加顺畅？

存储，管理架构和应用我们/他的变更集的最佳方法是什么？

提前致谢。

Answer 1

DBA不应该只在prod上调整过程。他们还应该使用源代码控制并将更改放在其他环境中，以便其他人进行更改时可以了解它们。

Answer 2

对数据库架构脚本进行任何和所有DDL更改，然后将其存储在源代码控制中。特别是你的DBA所做的改变 - 我建议你先让db开发人员和DBA检查你的基本模式和存储过程，然后再将它们检查到你的源代码控制中（引用HLGEM来说明它）。在应用之前，应该编写并批准移动到prod（即，如果DBA发现需要更改的内容，让DBA打开缺陷并通过该过程处理）。

将所有此类DDL更改锁定在开发人员之外。编写Java和C＃的聪明人应该与您的团队数据库“专家”沟通，了解如何最好地完成数据库方面的设计目标和需求。

将生产调整限制在那些高度依赖情况的情况下，例如，许多IT商店都有一名DBA，他将根据您的应用提供的数据库部署脚本定义物理存储设置，这通常是好的。一个带有你的应用程序的向导可以帮助经验不足的人以及一系列关于设置和基本调整的建议列表，这将有很长的路要走。