为什么要使用Oracle版本控制？

Question

在工作中，我们使用Oracle（12c客户端）来存储我们的大部分数据，并使用SQL Developer连接到数据库环境。

问题：

我们遇到的问题是由于某种原因而修改表（懒得创建新表，因此他们添加新列并更改数据类型或长度）。作为回报，这将打破其他实际利用它的人的目的。

更新的 我们有DEV，TST，UAT和PRD环境。在我们推广到珠三角之前，我们测试并批准了脚本。当我们想要返回现有表进行更改时，问题在于DEV，但该表已因各种原因而被修改。

问题1：

版本控制是仅针对存储过程还是可以跟踪对表结构，函数，触发器，序列，同义词等的更改？

Answer 1

正如Bob Jarvis所说，你需要的不仅仅是解决问题的方法。您需要为所有开发人员实施的策略和实践。我工作过的地方有一些想法：

• 每个开发人员都有一台安装了数据库副本的VM计算机。他们可以随心所欲地做任何事情但必须提供脚本以将他们的更改转移到生产中。这些脚本在投入生产之前应用于测试实例，并再次应用于QA实例。
• 颠覆适用于所有操作系统和乌龟在Windows上运行良好。将脚本提交到存储库运行良好，这与SQL开发人员集成，可以使用Toad完成。
• 您有权限问题。太多人拥有更改表的权限。删除这些权限并集中在一个或两个人身上。由于可以在那里应用脚本和监督，因此可以通过它们进行更改。开发人员可以使用自己的架构进行测试，也可以使用副本进行开发。

• 运行此脚本以查看谁可以更改表

  从DBA_TAB_PRIVS中选择* WHERE PRIVILEGE =＆＃39; ALTER＆＃39;

关键是分离关注点。开发人员应该可以访问他们可以执行所需操作的模式。公司需要知道谁做了什么，何时何地做了什么。

如果您有多个开发人员处理开发环境的多项更改，那么您需要协调和通信以及源代码管理。每周一次的会议讨论重叠区域或抬头聊天消息只是一些合作方式。

Answer 2

我认为最有效的方法是拥有一个DEV数据库，所有开发人员都可以管理自己的一组模式。

脚本版本提供了测试数据加载，以允许任何开发人员创建自己的工作架构。然后他在那里工作，测试他的更改，然后通过脚本将他的更改提交到源代码控制。 DEV数据库不需要很大，只需要足够的测试用例来进行单元测试。

编写所有更改的脚本，以便可以将它们签入版本控制系统，并与其他更改合并。目标是建立一个devA检查changeA的系统，然后当与主干合并时，devB在构建他的schemaA时获得changeA。

如果主项目架构使用PUBLIC同义词，则此方法需要小心。你需要在前进时考虑这个问题。

我还建议在随附的退出脚本中检查每个更改都应该签入。

这种方法的优点是开发人员可以管理自己的模式。使用脚本方法，他们不需要具备DBA知识，也不需要管理数据库。将所有这些集中在一个数据库上可以更容易地管理和控制资源。

我已经在拥有50多名开发人员的团队中使用了这种方法，而且效果非常好。

这种方法也为开发人员检查脚本并自动创建部署包铺平了道路。

可以做很多事情来使开发 - 测试 - 部署 - 回退周期更容易管理。