Oracle pl/sql 的 ORM
我正在使用 Oracle 为一家大公司开发企业软件。主要处理单元计划用PL/SQL 开发。我想知道是否有像 Hibernate for Java 那样的 ORM，但有一个用于 PL/SQL 的 ORM。我有一些想法如何使用 PL/SQL 和 Oracle 系统表创建这样一个框架，但很有趣 - 为什么以前没有人这样做过？您认为这对速度和内存消耗有何影响？为什么？
I am developing a enterprise software for a big company using Oracle. Major processing unit is planned to be developed in PL/SQL. I am wondered if there is any ORM like Hibernate for Java, but the one for PL/SQL. I have some ideas how to make such a framework using PL/SQL and Oracle system tables, but it is interesting - why no one have done this before? What do you think will that be effective in speed and memory consumption? Why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
ORM 的存在是为了在与数据库无关的语言（如 Java）和 DBMS（如 Oracle）之间提供接口。相比之下，PL/SQL 非常了解 Oracle DBMS，并且被设计为与它一起工作（并且比 Java + ORM 更高效）。因此，PL/SQL 和 Oracle DBMS 之间的 ORM 既多余又无用！
ORMs exist to provide an interface between a database-agnostic language like Java and a DBMS like Oracle. PL/SQL in contrast knows the Oracle DBMS intimately and is designed to work with it (and a lot more efficiently than Java + ORM can). So an ORM between PL/SQL and the Oracle DBMS would be both superfluous and unhelpful!
阅读这两篇文章 - 它们包含一些有趣的观点
问 Tom - 关系数据库设计与面向对象数据库设计
询问 Tom - 对象关系阻抗不匹配
Take a read through these two articles - they contain some interesting points
Ask Tom - Relational VS Object Oriented Database Design
Ask Tom - Object relational impedance mismatch
正如 Tony 指出的那样，ORM 确实充当了 App 和 Db 上下文边界之间的帮助者。
如果您正在数据库层寻找额外的抽象级别，您可能需要研究表封装。这是 2000 年代初的一个大趋势。如果您进行搜索，您会发现大量有关此主题的白皮书。
Plsqlintgen 似乎仍然存在于 http://sourceforge.net/projects/plsqlintgen/
As Tony pointed out ORMs really serve as helper between the App and Db context boundaries.
If you are looking for an additional level of abstraction at the database layer you might want to look into table encapsulation. This was a big trend back in the early 2000s. If you search you will find a ton of whitepapers on this subject.
Plsqlintgen still seems to be around at http://sourceforge.net/projects/plsqlintgen/
这个答案对将表包装在 pl/sql TAPI（表 API）中以进行 CRUD 操作的优缺点有一些相关的想法。
了解表 API 和事务 API 之间的差异
去年英国 Oracle 用户组对此进行了很好的小组讨论 - 总体结论是反对使用表 API 和事务 API，原因大致相同 - pl/sql 的优势在于 SQL 语句的过程控制，而 TAPI 则推动你不再编写基于集合的 SQL 操作，而是转向逐行处理。
TAPI 的论点是您可能想要强制执行某种访问策略，但 Oracle 提供了许多其他方法来执行此操作（细粒度访问控制、约束、插入/更新等触发器可用于填充默认值并强制调用代码传递有效的请求）。
我绝对建议不要将表包装在 PL/SQL 对象类型中。
pl/sql 的很多生产力来自于这样一个事实：您可以轻松地根据底层数据库结构来定义事物 - 行记录类型可以简单地定义为 %ROWTYPE，并且当表结构发生变化时将自动受到影响。
这也适用于基于这些类型的集合，并且有强大的批量操作可用于获取和保存。插入整个集合。
另一方面，每次您想要更改对象类型时，都必须显式地对其产生影响 - 每次表更改都需要影响并释放对象类型，从而使您的工作量加倍。
如果您使用继承和类型集合，则发布更改也可能很困难（您可以“替换”包，但一旦类型被另一种类型使用，就无法替换该类型）。
这并不是贬低 OO PL/SQL - 在某些地方它确实简化了代码（即避免代码重复，在任何明显可以从多态性中受益的地方） - 但最好理解并发挥该语言的优势，并且主要优点是该语言与底层数据库紧密耦合。
也就是说，我确实经常发现自己创建过程来构造默认记录、插入记录等 - 通常足以为其提供编辑器宏 - 但我从未找到一个好的论据来自动为所有表生成此代码（a创建大量未使用代码的好方法？？）
This answer has some relevant thoughts on the pros and cons of wrapping your tables in pl/sql TAPIs (Table APIs) for CRUD operations.
Understanding the differences between Table and Transaction API's
There was also a good panel discussion on this at last years UK Oracle User Group - the overall conclusion was against using table APIs and for transaction APIs, for much the same reason - the strength of pl/sql is the procedural control of SQL statements, while TAPIs push you away from writing set-based SQL operations and towards row-by-row processing.
The argument for TAPI is where you may want to enforce some kind of access policy, but Oracle offers a lot of other ways to do this (fine-grained access control, constraints, triggers on insert/update/etc can be used to populate defaults and enforce that the calling code is passing a valid request).
I would definitely advise against wrapping tables in PL/SQL object types.
A lot of the productivity with pl/sql comes from the fact that you can easily define things in terms of the underlying database structure - a row record type can be simply defined as %ROWTYPE, and will be automatically impacted when the table structure changes.
This also applies to collections based over these types, and there are powerful bulk operations that can be used to fetch & insert whole collections.
On the other hand, object types must be explicitly impacted each time you want to change them - every table change would require the object type to be impacted and released, doubling your work.
It can also be difficult to release changes if you are using inheritance and collections of types (you can 'replace' a package, but cannot replace a type once it is used by another type).
This isn't putting OO PL/SQL down - there are places where it definitely simplifies code (i.e. avoiding code duplication, anywhere you would clearly benefit from polymorphism) - but it is best to understand and play to the strengths of the language, and the main strength is that the language is tightly-coupled to the underlying DB.
That said, I do often find myself creating procedures to construct a default record, insert a record, etc - often enough to have editor macros for it - but I've never found a good argument for automatically generating this code for all tables (a good way to create a lot of unused code??)
Oracle 是一个关系数据库，也能够作为面向对象数据库工作。它通过在关系结构之上构建一个抽象层（相当自动地）来实现这一点。这似乎消除了对任何“工具”的需要，因为它已经是内置的。
Oracle is a Relation database and also has the ability to work as an object-oriented database as well. It does this by building an abstraction layer (fairly automatically) on top of the relational structure. This would seemingly eliminate the need for any "tool" as it is already built-in.