我是 Ruby 和 Rails 的新手，但在为 Oracle 构建前端方面已经有一段时间了。我也是面向对象设计（OOD）的新手，所以我可能也错过了一些重要的细节。无论如何，我有机会用 Ruby 和 Oracle 从头开始构建一个新产品（是的，它必须是 Oracle）。鉴于 Ruby 的全部 OO 特性，我认为尝试构建一个 OO 数据模型（或者，在 Oracle 的情况下，一个对象关系模型）是有意义的。然而，在我对 Rails 和 Oracle 对象的研究中，我没有找到解决方案，而是发现了一个令人不安的悖论。所以，我的基本问题是：我错过了什么吗？
更多细节
我目前看到的基本问题是 Rails 的 ActiveRecord 模块与 Oracle 对象不兼容，即因为它不支持复杂的数据类型，例如 Oracle 的对象类型（或者，如果支持，我还没有找到描述如何的文档）。因此，ActiveRecord 无法轻松处理包含对象和/或对象引用集合的 Oracle 表。简而言之，Rails 想要与数据库无关，Oracle Objects 想要与应用程序无关，而这两种理念目前被证明是冲突的。
论证要点的例子
我想做的是在应用程序和数据库中使用相同的对象定义来减少或消除对象关系映射。然而，因为 Rails 似乎没有在 Oracle 中创建或读取对象类型的功能，所以在 Oracle 中创建对象关系模型并改为创建关系模型是不值得的。反过来，这将产生极大地减少 Rails 应用程序中的 OO 模型的副作用。这就是悖论——Rails 的特性通过强制使用关系数据模型来实现数据持久性，从而固有地降低了它自己的 OOP 能力。
例如，假设我有许多不同类型的小部件。为了在 Oracle Objects 中支持这一点，我可能会创建一个小部件对象类型和各种小部件子类型。然后，我可能会创建一个具有属性的小工具对象，该属性包含对组成小工具的各种小部件类型和子类型的小部件引用的集合。这个对象模型对我来说听起来既简单又优雅，并且应该在 Ruby 中也能很好地工作。然而，将 Rails 和 ActiveRecord 放入等式中，我突然发现自己将模型扁平化为关系表，其中我有一个小工具表和一个小部件表（带有一个小部件类型列和各种其他列，以支持一个表中的各种小部件类型) 和两者之间的 1:N 表，用于将小部件附加到小工具。最后，我在 Rails 中的对象最终看起来与这些表非常相似，只有一种小部件对象类型，没有小部件对象子类型（小部件对象将仅具有指示类型的属性）。尝试在 Rails 中构建与表不匹配的对象模型听起来像是查询犯罪和惩罚的未来。这种被迫背离OOD的做法让我觉得很悲惨。当然，另一种方法可能是尝试完全规范化表并创建各种小部件子类型表，但这种方法在关系世界中并不总是很有意义（由于缺乏继承），并且会导致我的主要表连接头痛当前的项目。尝试在 Rails 中构建与表不匹配的对象模型听起来像是查询犯罪和惩罚的未来。这种被迫背离OOD的做法让我觉得很悲惨。当然，另一种方法可能是尝试完全规范化表并创建各种小部件子类型表，但这种方法在关系世界中并不总是很有意义（由于缺乏继承），并且会导致我的主要表连接头痛当前的项目。尝试在 Rails 中构建与表不匹配的对象模型听起来像是查询犯罪和惩罚的未来。这种被迫背离OOD的做法让我觉得很悲惨。当然，另一种方法可能是尝试完全规范化表并创建各种小部件子类型表，但这种方法在关系世界中并不总是很有意义（由于缺乏继承），并且会导致我的主要表连接头痛当前的项目。
将 Rails 放在一边，只专注于 Ruby， OCI8 接口似乎确实能够处理 Oracle 对象类型。但是，我还没有找到任何关于如何使用它的支持文档。这很明显，放弃 Rails 以开辟自己的道路的成本太高了（许多人发现 Oracle 对象本身使用起来很笨拙）。对于像这样的小项目，将 Rails 与关系 Oracle 一起使用要简单得多。
当我试图想象尝试通过 ActiveRecord 或类似模块支持对象数据类型所涉及的复杂性时，可以理解为什么尚未构建此功能（特别是考虑到 Rails 的与数据库无关的哲学）。可以理解……但很不幸。
所以。我错过了什么？是否有一种低影响且支持良好的方式来支持来自 Ruby 和/或 Rails 的 Oracle 对象？如果不是 Oracle，Rails 是否为任何对象关系数据库管理系统提供良好的对象类型支持？