数据仓库项目的存储过程与 JDO答案

【问题标题】：Stored procedures vs JDO for data warehousing project数据仓库项目的存储过程与 JDO
【发布时间】：2010-01-27 12:50:08
【问题描述】：

过去我们通过存储过程访问数据库。它们被视为管理数据的“更好”方式。我们将数据保存在数据库中，任何语言/平台都可以通过JDBC/ODBC/等方式访问。

然而，近年来，基于运行时反射/元数据的存储检索机制（如 Hibernate/DataNucleus）变得流行起来。最初我们担心它们会很慢，因为涉及额外的步骤（反射是昂贵的）以及当我们只需要一个字段时它们如何检索不必要的数据（整个对象）。

我开始计划一个使用 J2EE 的大型数据仓库项目，但我有点不确定是选择存储过程还是 JDO/JPA 等。最近一直在研究 Hibernate，老实说，我不会错过编写 CRUD 存储过程的机会！

基本上归结为：

存储过程
+ 可以在服务器上优化（虽然只有查询）
- 每个表可能有超过一千个存储过程：添加、删除、更新、getById 等。

JDO
+ 我不会在接下来的几个月里写 parameters.add("@firstNames", customer.getFirstName()); ...
- 会比 SP 慢（但大多数支持分页）

在我的情况下，你会为了什么而丰满。在这种情况下，我认为这是非常重要的。

谢谢，

约翰

【问题讨论】：

标签： java stored-procedures jakarta-ee data-warehouse jdo

【解决方案1】：

“JDO - 会比 SP 慢（但大多数支持分页）”

这个假设通常是错误的。 SP 没有理由特别快。我做了一些测量，它们并不比数据库外的代码快。

数据仓库的特点是仅插入加载和长时间运行的SELECT...GROUP BY... 查询。

您不是在编写 OLTP 事务处理。您没有使用 3NF 来防止更新/删除事务的更新异常。

由于您正在执行批量插入，因此 SP 肯定会比批量加载实用程序慢。批量加载程序通常是多线程的，并且会消耗所有可用的 CPU 资源。 SP 是 DB 的一部分，只能共享有限的 DB 资源。

由于您主要是在做SELECT GROUP BY，因此 SP 在这里也无济于事。 SELECT 语句不会因被包装在过程中而受益。

你不需要它们。他们没有帮助。

您可以轻松地对批量加载和查询进行基准测试，以证明 SP 没有帮助。

【讨论】：

【解决方案2】：

Rod Johnson 在他的“J2EE Design and Development”中写了一篇关于 ORM/StoredProcedures 的非常清晰的分析。他说

存储过程只应在 J2EE 系统中用于执行将始终大量使用数据库的操作，无论它们是在数据库中实现还是在与数据库交换大量数据的 Java 代码中实现。

当您计划实施数据仓库时，我认为存储过程方法是正确的选择。

【讨论】：

【解决方案3】：

我建议使用元数据来生成用于加载到数据仓库的脚本。这使您可以通过使用专门的加载工具以及存储过程（如果您使用的是足够古老的数据库）获得性能优势。此外，您可能最终会手动编写至少一些 SQL。将通用脚本作为存储过程完成后，您可以以相同的方式安排所有脚本，而不必担心在重写某些生成的代码以使其运行得更好时更改它们的调用方式。

至于获取数据，如果您在 J2EE 中构建的是一个报告工具，那么使用 JDO 可能会更好。虽然我对事情的报告方面不是很熟悉，但我可以看到的一个好处是，允许您的最终用户制作您事先没有预料到的自定义报告会更容易（尽管您仍然必须拥有他们可以做的一些限制，以便他们不会在此过程中删除数据库）。

【讨论】：