java - 用于数据仓库项目的存储过程与 JDO

Question

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

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

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

它基本上归结为:

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

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

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

谢谢，

约翰

Answer 1

“JDO - 将比 SP 慢(但大多数支持分页)”

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

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

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

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

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

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

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