ORACLE 中的逻辑分组模式？
我们正在为 ORACLE 11g 中的客户规划一个新系统。我已经在 Sql Server 领域工作了好几年了，并没有真正了解最新的 ORACLE 更新。
我想知道此时 ORACLE 是否添加了一个特殊功能，即数据库对象的某种逻辑“容器”，类似于 Sql Server 的 SCHEMA。
当尝试从 dev > 推送时，尝试使用 Sql Server 等 ORACLE 模式最终会成为代码比较的灾难。测试>居住。
包有点类似，只是您不能将表放入包中（因此它们实际上只适用于逻辑代码分组）。
我知道的唯一其他选择是必须在对象名称前添加“模式”前缀的过时做法，即 RPT_REPORTS、RPT_参数、RPT_日志、RPT_用户、 RPT_RUN_REPORT()，前缀RPT_表示这些是与我们的报告引擎打交道的所有对象。编写这样的系统感觉就像我们从未离开过 8.3 文件命名时代。
到目前为止，是否有任何更清晰、更直接的方法可以在 ORACLE 中将相关对象逻辑分组在一起？
We are planning a new system for a client in ORACLE 11g. I've been mostly in the Sql Server world for several years, and am not really current on the latest ORACLE updates.
One particular feature I'm wondering if ORACLE has added in by this point is some sort of logical "container" for database objects, akin to Sql Server's SCHEMA.
Trying to use ORACLE's schemas like Sql Server winds up being a disaster for code comparisons when trying to push from dev > test > live.
Packages are sort of similar, except that you can't put tables into a package (so they really only work for logical code grouping).
The only other option I am aware of is the archaic practice of having to prefix object names with a "schema" prefix, i.e. RPT_REPORTS, RPT_PARAMETERS, RPT_LOGS, RPT_USERS, RPT_RUN_REPORT(), with the prefix RPT_ denoting that these are all the objects dealing with our reporting engine say. Writing a system like this feels like we never left the 8.3 file-naming age.
Is there by this point in time any cleaner, more direct way of logically grouping related objects together in ORACLE?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Oracle 数据库对象的逻辑容器是模式。不知道你能得到多少“干净”和“直接”！你必须在这里进行范式转变。不要试图用 SQL Server 术语来思考，并强制采用类似于 Oracle 上的 SQL Server 的解决方案。熟悉 Oracle 的业务并从该角度解决您的问题。如果您知道自己在做什么，那么在 Oracle 中从开发推进到测试再到生产应该没有问题。
当您使用诸如“过时的实践”之类的术语时，您似乎对 Oracle 有一些不满。我建议您通过阅读一些内容来与 Oracle 非常丰富且强大的功能集交朋友，因为您显然已经致力于 Oracle 的这个项目。特别值得一读 Tom Kyte 所著的《Effective Oracle By Design》。读完本文后，请查看同一作者的“专家 Oracle 数据库架构”，更深入地了解 Oracle 的工作原理。您有责任让您的客户知道如何使用您收到的工具。谁知道？您甚至可能开始喜欢它。将其视为您工具箱中的另一个工具。你没有与 SQL Server 结婚，并且使用 Oracle 也不是不忠;-)
编辑：
回应 OP 的问题：
我不确定为什么这是一个后勤问题。它们可以被认为是独立的数据库，但实际上它们并不是。不，您不需要为每个模式使用单独的数据文件。单个数据文件通常用于所有模式。
如果您想要一个“漂亮的、独立的数据库”（如 SQL Server），只需创建一个模式来存储所有对象。问题结束。您可以创建其他用户/模式，只是不要赋予他们创建对象的能力。
有一些工具可以比较对象和数据，例如 PL/SQL Developer 比较。通常在 Oracle 中您想要比较模式，而不是整个数据库。我不知道为什么你想要有多个模式，每个模式都有自己的对象。是什么让你这么做？将您的对象（表、触发器、代码、视图等）保存在一个架构中。
Oracle's logical container for database objects IS the schema. I don't know how much "cleaner" and "more direct" you can get! You are going to have to do a paradigm shift here. Don't try to think in SQL Server terms, and force a solution that looks like SQL Server on Oracle. Get familiar with what Oracle does and approach your problems from that perspective. There should be no problem pushing from dev to test to production in Oracle if you know what you're doing.
It seems you have a bit of a chip on your shoulder about Oracle when you use terms like "archaic practice". I would suggest you make friends with Oracle's very rich and powerful feature set by doing some reading, since you're apparently already committed to Oracle for this project. In particular, pick up a copy of "Effective Oracle By Design" by Tom Kyte. Once you've read that, have a look at "Expert Oracle Database Architecture" by the same author for a more in-depth look at how Oracle works. You owe it to your customer to know how to use the tool you've been handed. Who knows? You might even start to like it. Think of it as another tool in your toolchest. You're not married to SQL Server and you're not being unfaithful by using Oracle ;-)
EDIT:
In response to questions by OP:
I'm not sure why that is a logistical problem. They can be thought of as separate databases, but physically they are not. And no, you do not need a separate data file for each schema. A single datafile is often used for all schemas.
If you want a "nice, self-contained database" ala SQL Server, just create one schema to store all your objects. End of problem. You can create other users/schemas, just don't give them the ability to create objects.
There are tools to compare objects and data, as in the PL/SQL Developer compare. Typically in Oracle you want to compare schemas, not entire databases. I'm not sure why it is you want to have multiple schemas each with their own objects anyway. What does is buy you to do that? Keep your objects (tables, triggers, code, views, etc.) in one schema.