2

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

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

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

它基本上归结为：

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

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

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

谢谢，

约翰

4

3 回答 3

2

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

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

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

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

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

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

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

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

于 2010-01-27T13:11:06.130 回答
1

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

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

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

于 2010-01-27T13:10:24.940 回答
0

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

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

于 2010-01-29T08:37:00.553 回答