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

2022-09-02 12:24:17

因此,我知道一些相对的差异,即与数据库具有“开放连接”,而以“断开连接”的方式工作。ResultSetRowSet

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

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

  • 从我的感觉来看,在断开连接模式下工作,特别是对于“只读”查询,在高度并发的系统中会有更好的性能。这是对的吗?如果是这样的话,可以肯定地说总是比只读查询更可取吗?RowSetRowSetResultSet

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

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

有什么想法吗?在我的知识中,有一些缺失的差距,这是显而易见的:)

我问的原因是我想在实现Spring-JDBC的接口和返回处理某些数据时进行选择。这个问题让我很好奇如何决定何时选择什么,除了扔硬币:)ResultSetExtractorSqlRowSet


答案 1

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

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

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

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

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

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

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


答案 2

行集

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

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

已连接的人永远不应该转义该方法,或者最坏的情况是转义创建它们的对象。至少使用 a,您可以断开连接,客户端不必关心实现。*除非您正在编写与特定功能或协定交互或依赖于特定功能或协定的特定库代码。ResultSet/RowsetRowSetJDBCResultSet

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

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

在大多数情况下,您希望具体化一个要操作和处理的域对象,而不是将代码直接耦合到 API。List/SetJDBC

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


推荐