【问题标题】:Database Data Filtering Best Practice数据库数据过滤最佳实践
【发布时间】:2014-08-01 16:30:00
【问题描述】:

我目前正在使用原始 JDBC 来查询 MySql 数据库中的记录;后续结果集中的每条记录最终都被提取出来,放置在特定领域的模型中,并存储到列表实例中。

我的问题是:在需要进一步过滤该数据的情况下(顺便说一下,基于 SAME 表中存在的列)以下哪种方法通常被认为是最佳做法:

1.进一步向数据库发出WHERE子句调用。这将有效地将过滤过程卸载到数据库,但显然会导致一个或多个连续应用多个过滤器的附加查询。

2.在应用程序级别显式过滤上述预处理列表,从而无需每次过滤记录时都必须对数据库进行额外调用。

3. 上述两种方法的某种混合组合,可能所有过滤操作最初由数据库服务器执行,但随后预处理为特定于应用程序的模型并隐式缓存到集合中一段时间​​。在此时间间隔内接收到的进一步过滤器查询将由缓存中存储的数据提供服务。

需要注意的是,这个场景中的数据库服务器实际上位于 一台外部机器,因此通过本地网络发送查询流量的开销和延迟也必须考虑到我们最终选择采用的方法中。

我清楚地知道古老的口头禅:“数据库服务器应该被用来做它擅长的事情。”然而,在这种情况下,对数据库进行大量调用以过滤我已经在应用程序级别拥有的数据似乎是一个不够充分的解决方案。

您的想法和见解将不胜感激。

【问题讨论】:

    标签: java mysql jdbc


    【解决方案1】:

    我在许多应用程序中都使用了混合方法,并取得了不错的效果。

    数据库过滤特别适用于索引列。这减少了网络开销,因为发送到应用程序的行更少。

    根据结果中的行数和索引的缺乏,某些列的数据库过滤可能非常慢。与数据库查询时间相比,网络开销可以忽略不计,因此在这种情况下应用程序过滤可能会更快。

    我还发现 Java 中的应用程序过滤比复杂的 SQL 更易于编写和理解。

    我通常手动尝试使用纯 SQL 在合理的时间内获取最少的行。然后编写 Java 以细化到所需的行。

    【讨论】:

      【解决方案2】:

      首先我很欣赏这个问题...因为几天前我也遇到过类似的情况...因为您已经讨论了所有可用的选项我更喜欢使用第二个选项...我的意思是在应用程序级别而不是在处理在数据库级别过滤。

      【讨论】:

        猜你喜欢
        • 2013-02-04
        • 1970-01-01
        • 1970-01-01
        • 2020-08-01
        • 1970-01-01
        • 2012-09-16
        • 1970-01-01
        • 2010-11-06
        • 2018-11-19
        相关资源
        最近更新 更多