用 SQL 或 Java 过滤数据？ [关闭]答案

【问题标题】：Filter data in SQL or in Java? [closed]用 SQL 或 Java 过滤数据？ [关闭]
【发布时间】：2011-12-20 01:18:35
【问题描述】：

过滤数据的一般准则/规则是什么？我习惯于在 WHERE 子句中的 SQL 语句中看到过滤器，尽管有时过滤器会给 SQL 带来复杂性，使其庞大且对于中级开发人员来说乍一看很难阅读，但编写良好的那些看起来很复杂是经过良好调整和优化的。过滤也可以在 Java 中完成，但这当然有一个缺点，即来自 SQL 的未过滤数据可能很大，并且仅将其加载到内存中以将其过滤掉可能是浪费的。当然，如果您有多个数据源作为过滤器所需的依赖项，那么您别无选择，只能在 Java 中进行过滤。

【问题讨论】：

这取决于？我可以想象应用程序端（Java）或数据库端（SQL）过滤是理想的情况......取决于数据的大小，需要多少往返，运行的开销是多少每次过滤器更改时查询......等等......

标签： java sql filter

【解决方案1】：

尽可能在后端 (sql) 上进行过滤。如果这使得查询对于初级开发人员来说过于复杂，那就这样吧。虽然代码的清晰性很重要，但您不应该根据初级开发人员对它的理解程度来做出设计决策——他能够使用它就足够了。

在谈论不同层时尤其如此，您的初级开发人员可能不知道任何 SQL，那么您会完全避免使用 SQL 后端吗？

编写的 SQL 尽可能清晰（不牺牲性能），但这样做的前提是维护它的人会熟悉 SQL 以及应该如何使用它。当像这样跨层时，有点“更容易理解”真的会扼杀你的性能（从数据库中拉回数据以更新它，可能比数据库上的更新花费数千倍的时间，不恰当地使用游标可能比基于集合的解决方案要差得多）。

【讨论】：

感谢您的意见，我的问题有点类似于性能与可读性/可维护性。我认为这是一个很好的指导方针，首先要考虑其他因素。
@CarlosJaimeC.DeLeon：这是一个层内的重要考虑因素，但不是跨层。跨层，除了非常糟糕的性能，最重要的是要考虑的是适当性；应该在这一层还是那一层处理。在层内，可读性应该被认为比性能更重要。但是，如果您决定最好在 lisp 中完成您的业务逻辑，请不要仅仅因为您的大多数开发人员更熟悉 vbscript/java/F# 等而跳过您的业务逻辑。
只是一点点，SQL上过滤所有的小东西不是把大量的业务逻辑放在数据访问层吗？
@user1186523：不是真的。数据层已经知道数据结构，您只需提供标准术语（通常是键）来过滤将返回的数据。
@jmoreno 比如你在数据访问层写了一个getUnpaidInvoices方法，你不是在上面放业务逻辑吗？无偿是一种业务逻辑，但您不能在服务层中加入表格...

【解决方案2】：

如果数据已经在数据库中，那么在其中进行过滤更有意义，因为 RDBMS 将针对此类工作进行优化。如果过滤可能会让新手和中级开发人员感到困惑，为什么不将其隐藏在视图中，并且只向相关用户授予对视图的访问权限？

【讨论】：

【解决方案3】：

我想没有明确的答案。这取决于个人用例。根据所考虑的应用程序，Java 和 SQL 中的过滤都可以适用。

正如您所提到的，SQL 中的过滤会使查询变得复杂且成本高昂。但与此同时，这可以通过数据库调整、放置适当的索引、表分区等来改进。特别是在数据库设计仍在发展的情况下，您可以进行这些类型的更改。
如果您正在使用已设计数据库的系统，并且您几乎没有任何重大更改的空间（因此没有太多的查询/数据库优化），在这种情况下，在 java 中进行过滤是更好的选择。

这一切都取决于具体的用例。

【讨论】：

在“Java”中过滤更好的情况非常罕见，不值得一提。在数据库级别过滤通常比获取所有数据然后过滤更快，并且从不慢。
是的。这种情况确实很少见，如果您需要，那么这意味着数据库模式设计中存在一些问题。同样正如 OP 所提到的，如果您要处理多个数据源，那么这将成为必要。