ResultSet 与 RowSet：选择哪一个以及何时选择？
因此，我意识到一些相对差异，即 ResultSet 具有与数据库的“开放连接”，而 RowSet 以“断开连接”的方式工作。
但这几乎就是我的理解（可能不正确）：
我的问题是——在什么情况下，其中一种比另一种更可取？他们各自的优点/缺点是什么？
据我所知，
RowSet，工作于 断开连接模式特别适用于 “只读”查询，将有 更好的性能在高度 并发系统。这是正确的吗？ 如果是这样的话可以肯定地说RowSet总是优于ResultSet用于只读查询？如果我的迭代是正确的
RowSet不会抛出 SQL 异常， 但这有好处吗？另一个 因为RowSet是可序列化的。 但我的担忧主要来自于 绩效视角会是什么 选择？但是这对于 读写查询？？你能同步吗 ResultSet返回DB？ （我不是 确定这是否可能（可能是 我只是不记得或谷歌 已经足够好了:)已经有一段时间了 使用原始 JDBC...
有什么想法吗？很明显，我的知识中存在一些缺失的差距：）
我问的原因是我想在实现 Spring-JDBC 的 ResultSetExtractor 接口与返回 SqlRowSet 之间进行选择处理一些数据。这个问题让我很好奇除了抛硬币之外，如何决定什么时候选择:)
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.
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 sayRowSetis always preferable toResultSetfor readonly queries?If I'm correct iterating over the
RowSetdoesn't throw SQL Exceptions,
but is that a benefit? The other
being thatRowSetis 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...
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 :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不同意JR的回答。 RowSet 通常是一个不错的选择，但一如既往，最佳答案取决于您的情况和需求。对所有内容使用 RowSet 不会产生功能失调的代码，但它的性能可能比 ResultSet 慢（常见的 JdbcRowSet 实现是 ResultSet 的包装器）。
如果您需要在需要 JavaBean 的模块化代码中使用结果对象，那么 RowSet 可以满足 Java Bean 的最低要求。
如果您正在为多线程/服务器应用程序开发代码，那么您必须接受这样一个让步：所有 Java Bean 都是可变的，因此不是线程安全的。因此，结果集和行集都不是线程安全的。
如果您正在编写使用数据库查询并将其转换为 Java 数据模型对象以在应用程序的其余部分中使用的代码，那么 RowSet 的性能可能会低于 Resultsets。
在我编写的大量代码中，当我收到 JDBC 数据库查询时，我只是使用结果集立即将检索的行处理为数据模型对象列表。结果集甚至无法在执行翻译的方法调用后继续存在。在我看来，这很好......因为结果集（以及行集）消耗大量资源，并且您希望它们尽快可供 gc 使用。
在这种模式下，我什至不需要 Resultset 的任何新功能，更不用说 RowSet 了。我只需向前迭代一次集合并生成结果行列表。
在某些情况下，行集是非常理想的。由于 RowSet 是可序列化的并且表面上是“轻量级”的，因此断开连接的 CachedRowSet（例如）代表了一种在位置之间传输数据库查询结果的相当有效的机制，特别是如果您希望数据可就地更新的话。当然，您也可以序列化并传输对象列表。
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).
If you need to use your result object in modular code that requires a JavaBean, then RowSets meet the minimum requirements for Java Beans.
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.
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.
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.
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.
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 ，这是我在数据处理时总是使用的将适合内存，这样我就可以尽快将连接释放回池中以供重用。ResultSet永远不应该成为公共合约的一部分。连接的 ResultSet/Rowset 永远不应该转义该方法，或者最坏的情况是转义创建它们的对象。至少使用
RowSet您可以断开它的连接，并且客户端不必关心实现。 *除非您正在编写与ResultSet特定功能或协定交互或依赖于JDBC特定库代码。如果您只是传输查询结果，
JDBC特定类应该成为您公共契约的一部分。理想情况下，您希望将 RowSet/ResultSet 内容具体化为类型安全的域对象以进行传递。
在大多数情况下，您希望具体化领域对象的
List/Set来进行操作和使用，而不是将代码直接耦合到JDBCAPI。许多现代的
ResultSetMapper类都可以使用Visitor模式来处理生成类型安全的域实例，因为这是惯用的处理方式。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 disconnectedCachedRowSetwhich 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.ResultSetshould never be part of a public contract.A connected
ResultSet/Rowsetshould never escape the method or at worst the object that created them. At least with aRowSetyou can disconnect it and the client doesn't have to care about the implementation. *Unless you are writingJDBCspecific library code that interacts or relies onResultSetspecific features or contracts.If you are just transferring the results of a query,
JDBCspecific classes should be part of your public contract.Ideally you want to materialize
RowSet/ResultSetcontents to typesafe Domain Objects to pass around.In most cases you want to materialize a
List/Setof domain objects to manipulate and work with instead of coupling your code directly to theJDBCapi.Many modern takes on a
ResultSetMapper<T>class exist to handle generating typesafe domain instances using aVisitorpattern because this is the idiomatic way of doing things.