Java JDBC 结果集与行集选择哪一个以及何时选择?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/6599625/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-16 08:06:03  来源:igfitidea点击:

JDBC Resultset vs Rowset which one to choose and when?

javaspringjdbcspring-jdbcrowset

提问by PhD

So I'm aware of some relative differences i.e., the ResultSet has an 'open connection' to the database whereas a RowSet works in a 'disconnected' fashion.

所以我知道一些相对差异,即 ResultSet 与数据库有一个“开放连接”,而 RowSet 以“断开连接”的方式工作。

But that's pretty much what I understand (may be incorrect :)

但这几乎是我的理解(可能不正确:)

My question is then this - under what circumstances is one preferable over the other? What are each of their strengths/weaknesses?

那么我的问题是 - 在什么情况下一种比另一种更可取?他们各自的优势/劣势是什么?

  • From what I feel a RowSet, working in disconnected mode especially for "read-only" queries, would have better performance in a highly concurrent system. Is that correct? If that's the case is it safe to say RowSet is always preferable to ResultSet for readonly queries?

  • If I'm correct iterating over the RowSet doesn't throw SQL Exceptions, but is that a benefit? The other being that RowSet is serializable. But my concern is primarily from a performance perspective what would be the choice?

  • But does it even matter for read-write queries?? Can you sync the ResultSet back to the DB? (I'm not sure if that's possible (It may be and I just can't recollect or google it well enough :) It's been a while with raw JDBC...
  • 从我的感觉来看,在断开连接模式下工作的 RowSet,尤其是对于“只读”查询,在高度并发的系统中会具有更好的性能。那是对的吗?如果是这种情况,可以说 RowSet 总是比 ResultSet 用于只读查询更可取吗?

  • 如果我正确迭代 RowSet 不会抛出 SQL 异常,但这是一个好处吗?另一个是 RowSet 是可序列化的。但我的担忧主要是从性能的角度来看会是什么选择?

  • 但它甚至对读写查询重要吗??你能将 ResultSet 同步回数据库吗?(我不确定这是否可能(可能是,我只是无法回忆或用谷歌搜索它是否足够好:)原始 JDBC 已经有一段时间了......

Any ideas? There are some missing gaps in my knowledge as is evident :)

有任何想法吗?很明显,我的知识中存在一些缺失的空白:)

The reason I ask is I'd like to choose between implementing Spring-Jdbc's ResultSetExtractor Interface versus return an SqlRowSet when processing some data. This question just got me curious to how to decide what to choose when, other than tossing a coin :)

我问的原因是我想在处理某些数据时在实现 Spring-Jdbc 的 ResultSetExtractor 接口与返回 SqlRowSet 之间做出选择。这个问题让我很好奇如何决定何时选择什么,而不是扔硬币:)

采纳答案by PhD

RowSet

行集

RowSetis almost always the right choice, it is more full featured and has all the benefits you listed as well as having specialized implementations for special purposes, like the disconnected CachedRowSetwhich is what I always use when the data will fit into memory, so I can release the connection back to the pool as quickly as possible to be reused.

RowSet几乎总是正确的选择,它功能更全,具有您列出的所有好处,并且具有用于特殊目的的专门实现,例如断开连接CachedRowSet,这是我在数据适合内存时总是使用的,因此我可以释放连接尽快回到池中以被重用。

ResultSetshould never be part of a public contract.

ResultSet永远不应成为公共合同的一部分。

A connected ResultSet/Rowsetshould never escape the method or at worst the object that created them. At least with a RowSetyou can disconnect it and the client doesn't have to care about the implementation. *Unless you are writing JDBCspecific library code that interacts or relies on ResultSetspecific features or contracts.

连接ResultSet/Rowset不应该逃避方法或最坏的创建它们的对象。至少使用 aRowSet您可以断开它,并且客户端不必关心实现。*除非您正在编写JDBCResultSet特定功能或合同交互或依赖的特定库代码。

If you are just transferring the results of a query, JDBCspecific classes should be part of your public contract.

如果您只是传输查询结果,则JDBC特定类应该是您的公共合同的一部分。

Ideally you want to materialize RowSet/ResultSetcontents to typesafe Domain Objects to pass around.

理想情况下,您希望将RowSet/ResultSet内容具体化为类型安全的域对象以进行传递。

In most cases you want to materialize a List/Setof domain objects to manipulate and work with instead of coupling your code directly to the JDBCapi.

在大多数情况下,您希望实现一个List/Set域对象来操作和使用,而不是将代码直接耦合到JDBCapi。

Many modern takes on a ResultSetMapper<T>class exist to handle generating typesafe domain instances using a Visitorpattern because this is the idiomatic way of doing things.

许多现代采用一个ResultSetMapper<T>类来处理使用Visitor模式生成类型安全域实例,因为这是做事的惯用方式。

回答by scottb

I disagree with JR's answer. The RowSet is often a good choice, but as always, the best answer depends on your situation and your needs. Using a RowSet for everything won't yield dysfunctional code, but it can offer slower performance than a ResultSet (the common JdbcRowSet implementation is a wrapper for a ResultSet).

我不同意JR的回答。RowSet 通常是一个不错的选择,但与往常一样,最佳答案取决于您的情况和需求。对所有内容使用 RowSet 不会产生功能失调的代码,但它可以提供比 ResultSet 更慢的性能(常见的 JdbcRowSet 实现是 ResultSet 的包装器)。

If you need to use your result object in modular code that requires a JavaBean, then RowSets meet the minimum requirements for Java Beans.

如果您需要在需要 JavaBean 的模块化代码中使用结果对象,则 RowSet 满足 Java Bean 的最低要求。

If you are developing code for a multithreaded/server app, then you must accept the concession that all Java Beans are mutable and therefore not thread-safe. As a result, neither Resultset nor RowSets are thread safe.

如果您正在为多线程/服务器应用程序开发代码,那么您必须接受所有 Java Bean 都是可变的,因此不是线程安全的这一让步。因此,Resultset 和 RowSet 都不是线程安全的。

If you are writing code that consumes database queries and translates them into Java data model objects for use in the rest of your application, then it is likely that RowSets are less performant than Resultsets.

如果您正在编写使用数据库查询并将它们转换为 Java 数据模型对象以供应用程序其余部分使用的代码,那么 RowSet 的性能可能低于 Resultsets。

In a lot of code that I've been writing, when I receive a JDBC database query, I've been simply using the Resultset to process the retrievd rows immediately into a List of data model objects. The Resultset doesn't even survive the method call that performs the translation. In my opinion, this is good ... because Resultsets (and therefore RowSets) consume a lot of resources, and you want them to be available for gc as soon as you can.

在我编写的许多代码中,当我收到 JDBC 数据库查询时,我只是使用 Resultset 将检索到的行立即处理为数据模型对象列表。结果集甚至无法在执行翻译的方法调用中幸存下来。在我看来,这很好……因为结果集(以及因此行集)消耗了大量资源,并且您希望它们尽快可用于 gc。

In this mode, I don't even need any of the newer features of Resultset, let alone RowSet. I simply iterate forward once through the set and generate a List of result rows.

在这种模式下,我什至不需要 Resultset 的任何新功能,更不用说 RowSet。我只是在集合中向前迭代一次并生成结果行列表。

There are situations in which RowSets are highly desirable. Since RowSets are serializable and ostensibly "lightweight", the disconnected CachedRowSet (for example) represents a reasonably efficient mechanism for transmitting database query results between locations, particularly if you want the data to be updateable in situ. Of course, you could also serialize and transmit a List of objects.

在某些情况下,非常需要 RowSet。由于 RowSet 是可序列化的并且表面上是“轻量级”的,因此断开连接的 CachedRowSet(例如)代表了一种在位置之间传输数据库查询结果的合理有效的机制,特别是如果您希望数据可就地更新时。当然,您也可以序列化和传输对象列表。