19

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

但这几乎是我所理解的（可能不正确）：

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

  • 从我的感觉来看RowSet，在断开连接模式下工作，特别是对于“只读”查询，在高度并发的系统中会有更好的性能。那是对的吗？如果是这种情况，是否可以肯定地说 对于只读查询RowSet总是更可取 ？ResultSet

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

  • 但它甚至对读写查询有影响吗？您可以将 ResultSet 同步回数据库吗？（我不确定这是否可能（它可能是，我只是无法很好地回忆或谷歌搜索它:) 原始 JDBC 已经有一段时间了......

有任何想法吗？很明显，我的知识中有一些缺失的空白:)

我问的原因是我想在处理一些数据时在实现 Spring-JDBC 的ResultSetExtractor接口和返回之间进行选择。SqlRowSet这个问题只是让我好奇如何决定何时选择什么，而不是扔硬币:)

4

2 回答 2

25

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

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

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

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

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

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

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

于 2013-06-15T00:15:09.393 回答
10

行集

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

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

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

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

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

在大多数情况下，您希望具体化一个List/Set域对象以进行操作和使用，而不是将您的代码直接耦合到JDBCapi。

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

于 2011-07-06T18:49:36.390 回答