关于 Oracle 版本控制系统的建议
在工作中，我们使用 Oracle (ick) 作为客户端的数据库（这是从以前公司的项目迁移而来的，因此不幸的是，数据库是一成不变的）。 直到现在，这还没有引起任何大的麻烦（除了通常的 Oracle 与 MSSQL 的问题）：我们正处于这样一个阶段：五个独立的开发人员正在为系统开发五个单独的增强功能，每个增强功能都使用 Perforce 中的不同分支。
任何人都可以建议一种跟踪 Oracle 版本更改的好方法：主要是存储过程，但也（可能）对表体系结构进行更改？
目前，我们只是将“创建或替换”脚本附加到 FogBugz 案例中，但有时这会导致更改被忽视，这很快就会导致令人头痛！
注意，数据库本身不可能有多个副本，因为它太大了。
At work we are using Oracle (ick) for the database of a client (this is a migration from a previous company's project, so the database was set in stone, unfortunately).
This has not caused any major headaches (save from the usual Oracle vs. MSSQL stuff), until now: We're at a point where five seperate developers are developing five seperate enhancements for the system, each using a different branch in Perforce.
Can anyone suggest a good way to keep track of version changes in Oracle: mainly Stored Procedures but also (possibly) changes to the table architecture?
At the moment we're simply attaching 'Create or replace' scripts to FogBugz cases, but there have been times when this has caused changes to go unnoticed, whcih quicky propagates to a large headache !
N.B. it's not possible to have more than one copy of the database itself, as it's just far too big.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Database source control with Oracle之前曾提出过一个非常类似的问题，我然后回答道。
总结 - DDL 和存储过程是应该在版本控制工具中管理的代码，就像 Java、C# 或其他工具一样。
A very similar question was asked before Database source control with Oracle which I answered then.
Summary - DDL and Stored Procedures are code which should be managed in a version control tool just like Java, C# or whatever.
你没有说你正在使用哪个版本的Oracle，我怀疑它不太可能是
最新的。但如果您使用 11gR2，那么您应该阅读版本功能。
基于版本的重定义使我们能够管理数据库内不同版本的 PL/SQL 对象。它不会取代适当的版本控制，而是通过允许模式的不同版本在同一实例中共存来对其进行补充。非常酷。 了解详情。
You don't say which version of Oracle you're using, and I suspect it is unlikely to be the
very latest. But if you are using 11gR2 then you should read up on the Editions feature.
Edition-based redefinition allows us to manage different versions of PL/SQL objects inside the database. It doesn't replace proper version control, but supplements it by allowing different versions of a schema to co-exist in the same instance. It's very cool. Find out more.
如何在 SVN 中检查程序的脚本，用 FB 案例编号标记每次检查，以便可以直接在 FB 中看到更改？
这就是我们对脚本所做的事情（主要是 MSSQL），但我们使用 Jira 代替 FB。
How about checking in the script for the procedures in SVN, tagging each checking with FB case number so that the changes can be seen directly in FB ?
That's what we do for our scripts (MSSQL mostly) but instead of FB we use Jira.
正如 ACP 所说，版本功能运行良好如果您拥有最新、最好的 Oracle 版本，则可以执行此操作。
无论如何，其他链接的答案显示要走的路 - 将所有 PL/SQL 维护在版本控制中，并将所有 DDL 更改保留为补丁，这些更改也输入到版本控制中。
一些可能会影响您的案件的实际情况。
如果您有相对统一的数据库结构和快速变化的 PL/SQL 包，那么一种选择是使用一个模式来保存表和 PL/SQL 包的主分支，并为每个开发人员提供一个单独的模式用于他们的 PL/SQL 分支包。主模式中的所有表都与每个开发人员的模式同义。
因此，您可以针对单个数据存储运行多个 PL/SQL 版本。当开发人员分支聚集在一起时，这些分支将被签入主分支并编译到主应用程序模式中。
我发现在每个开发模式中包含所有 pl/sql 包更容易，而不仅仅是当前正在开发的包，但您可以使其以任何一种方式工作。
显然，您仍然需要至少 2 个数据库，以便您的生产环境免受所有这些恶作剧的影响。
如果这对您不起作用，另一种选择是为每个开发人员提供自己的数据库来进行修改。您说这里的大小是一个阻碍因素，但是您可以使用数据泵中的功能来限制从主数据库传输到每个开发人员数据库的行数。
例如：
仅导出 5% 的行...
仅导出特定表的 5%...
通过这种方式，每个开发人员都可以使用相同的数据库结构，但不会遇到相同的存储问题。
希望这有帮助。
As ACP said, the Editions feature would work well for this if you have the latest and greatest version of Oracle.
In any case, the other linked answer shows the way to go - have all PL/SQL maintained in version control and keep all DDL changes as patches, which are also entered into version control.
A few practicalities that might affect your case.
If you have a relatively unified database structure and rapidly changing PL/SQL packages then an option is to have one schema holding the tables and the main branch of PL/SQL packages, and give every developer a separate schema for their branch of PL/SQL packages. All tables in the main schema are synonymed over to each developer's schema.
So, you have multiple PL/SQL versions running against a single data store. As developer branches come together these are checked into the main branch and compiled into the main application schema.
I find it easier to have all pl/sql packages in each development schema, not just the ones currently in development, but you can make it work either way.
Clearly you still need at least 2 databases so your production environment is safe from all these shenanigans.
Another option if this just doesn't work for you is to give each developer their own database in which to tinker. You said that size is a prohibitive factor here, but you could use the features in Data Pump to restrict the number of rows that are transferred from the main database to each developer database.
For example:
To only export 5% of the rows...
To only export 5% of a specific table...
In this way each developer can work with the same database structure but you don't have the same storage issues.
Hope this helps.