将结构化数据传入和传出 Oracle 的最佳（最快、最简单、最有效）方法是什么答案

【问题标题】：What is the best (fastest, easiest, most efficient) way to pass structured data into and out of Oracle将结构化数据传入和传出 Oracle 的最佳（最快、最简单、最有效）方法是什么
【发布时间】：2010-12-03 22:54:27
【问题描述】：

我想通过让应用程序将数据库视为服务来从应用程序层抽象出一个大型数据库存储（关系型，OLTP）。这样做的自然方法是调用 sprocs，但传统上它们遵循 CRUD 范式，并且与我的抽象思想保持一致，我想抽象出数据库中数据结构的所有知识并专注于业务流程。

所以不要让“保存发票”业务流程变成这样......

开始交易
创建发票抬头
对于发票行项目
1. 创建发票行项目
提交事务

...相反，我想将代表发票的结构化数据传递到数据库中。

我可以传递包含发票的 XML 文档，但这是我希望在数据库端避免的：

解析 XML
XML 验证
参数提取和绑定到 Oracle PL/SQL 对象中

偏离路线，在所有情况下，无论解决方案如何，都必须这样做。但是，我不想支付 XML 文档罚款（尖括号税）。

因此问题是 - 在 Oracle 存储过程中发送和接收数据以及将数据结构化的最有效方法是什么？

我想听听那些想要支持 JSON、ATOM 或其他格式的人的意见。

还可以考虑使用本机或二进制机制来实现这一点。在 Oracle 表（内存数据集）中构建和发送呢？有没有人这样做过？你的经历在哪里？

【问题讨论】：

尖括号税？它并没有他们希望你相信的那么糟糕，特别是如果你使用正确的技术......谷歌“最快的 XML 解析器”应该给你一个很好的起点

标签： xml oracle

【解决方案1】：

您可以创建一个集合，在客户端填充它，将它传递给Oracle 过程并使用它进行基于集合的操作：

INSERT
INTO    dest_table
SELECT  *
FROM    TABLE(:mycollection)

【讨论】：

【解决方案2】：

这取决于。您可以将任何形式的数据存储为 LOB。没有人这样做的主要原因是您将数据存储在数据库中，以便您可以通过它搜索。在 Google 出现并让查找事物成为可能之前，互联网是一个不错的主意。

所以你必须以某种方式解析数据。您可以在客户端解析它并发送 SQL 插入/更新。如果您使用您最喜欢的 OO 语言执行此操作，您将拥有一个 OR 映射器（它可以在普通 SQL 表中加载和保存“对象”）。这样，繁重的工作（解析）在许多客户端上完成，而数据库只存储和搜索数据。

【讨论】：

【解决方案3】：

我想通过让应用程序将数据库视为服务来从应用程序层抽象出一个大型数据库存储（关系型，OLTP）。

这就是 DAO 层的用途。对于应用程序代码，DAO 是一个持久层（用您的话来说是服务）。 DAO 知道如何存储结构化文档。

我认为您必须对存储的文档进行 SQL 查询。

虽然存在特定于 Oracle 的 XML 格式，但我会避免使用它，因为它会将您的代码与 Oracle 联系起来。只要标准 SQL 有效，就使用它。

【讨论】：

是的，当然每个人都知道 DAO 对象。它们从 DB 中抽象出应用程序，但它们本身会受到 DB 变化的影响。如果我们只考虑调用存储过程，我们可以进一步抽象这一层。根据我的示例，这通常通过调用“CreateInvHeader”和“CreateInvDetails”来实现。这不是业务流程级别的完整抽象，这是我想要实现的。现在，如果我将结构化文档传递给数据库，我将获得更好的抽象，并且几乎不需要构建 aDAO 层。在拥有专门的数据库开发人员的大型团队中，这可能是一个加分项。
抱歉，抽象应该在某处停止。 :) 作为一个 Java 程序员，我更喜欢把它停在 DAO 层，它知道数据存储的细节。

【解决方案4】：

我不明白为什么要对数据库执行“解析”和“验证”之类的操作。

可能是我们在工作中使用了负载非常重的数据库，所以我的观点有点主观，但基本上可以在数据库之外完成的任何事情都是在外部完成的，因为数据库是大多数应用程序的瓶颈（并且'outside' 可以很容易地并行化）。

这是我们在工作中使用的：

|身份证 |索引 1 |索引 2 |索引 3 | ... |大块数据 |

基本上，索引允许搜索，并且“大数据块”在应用程序的控制之下。它通常是压缩的序列化（版本化）数据（有些团队在这个 blob 中存储大约 300KB ;)）。

当然，这需要前端（或库）以统一的方式实际执行序列化+压缩或解压+反序列化。

它运作良好，...但正如我所说，数据库对我们来说是一个瓶颈，所以我们尝试尽可能地将负载外部化。

【讨论】：

如果我们传入 json/atom 或 xml，我们需要解析和验证入站消息。特别是，如果我们想将 DB 视为（内部）服务，那么我们将需要解析和验证入站数据，而不是用于业务规则，但足以将数据解析为表字段。通过您的示例，我看到您正在考虑将关系数据库作为 ObjectDB。很有趣。
为什么还要使用数据库？如果您只是存储带有索引的 blob，还有其他方法可以做到这一点，例如ISAM 文件。使用您的存储方案，无论如何您都会失去 95% 的 RDBMS 功能。
我们同意...不幸的是，技术选择受到环境的限制。我们需要一个可以从一百台不同的机器访问的存储点，这些机器处理交易原则并遵守 ACID 法律。需要支持每秒大约 1500 次读取。 Oracle 做到了，我们已经有很多 Oracle 实例。

【解决方案5】：

也许研究对象-关系视图。

请参阅这些链接以获取起点...

Oracle 9i Docs - "Applying an Object Model to Relational Data"

Ask Tom - "Relational VS Object Oriented Database Design"

【讨论】：

【解决方案6】：

由于您使用 Oracle，在存储过程中解析 XML 并不是什么大问题。 IMO 只有三种明智的选择：

在知道数据库结构的客户端上使用 DAO
使用存储过程，让你有一点抽象
使用 XML

任何其他结构化文本格式（JSON 等）都较差，因为 XML 是您在 Oracle 中已经拥有解析器的格式。

【讨论】：