我应该将此过滤放在 SQL 或我的应用程序代码中吗？答案

【问题标题】：Should I put this filtering in SQL or my application code?我应该将此过滤放在 SQL 或我的应用程序代码中吗？
【发布时间】：2015-10-25 11:42:04
【问题描述】：

假设我的网络应用程序中有以下模型：

Table User:
   (attr1, attr2, attr3, ...)
Table Prize:
   (condition1, condition2, condition3, prize_val)

应用逻辑是：如果一个用户满足奖品的所有条件，我想给他奖品。条件可以是 NULL（所有用户都为真）或特定值。每个条件都可以用用户属性计算。我可以通过两种方式进行过滤：

从数据库中获取所有奖励规则（最多100条），并在我的应用程序代码中迭代规则，检查当前用户是否满足规则，以获得奖励列表。
用户 SQL 执行如下过滤：

SELECT prize from Prize where (condition1=NULL or condition1=user_condition1) and (condition2=NULL or condition2=user_condition2) ...

我的问题是：哪个效率更高？

一个更普遍的问题是：什么时候在应用程序代码中进行过滤而不是 SQL 更好？

PS。我什至考虑在代码中进行迭代的原因是：如果我在代码中进行迭代，并且 condition1 为 NULL 作为奖品，我不需要为用户计算 condition1 值（这种计算可能很昂贵）；但是如果我采用 SQL 方法，我必须为用户预先计算每个条件值。

【问题讨论】：

这取决于如何配置您的条件。如果您有动态条件（它们的数量会有所不同），可能带有NULL 的代码会更容易实现。如果您有静态条件，那么SQL 似乎更好。通常，即使您必须使用 NULL SQL 重新计算每个条件，也会比迭代快得多。
您能否编辑您的问题以更详细地显示 2 个表格的外观。因为正如我现在看到的那样，条件在列中。它们也可以成行排列，以实现更动态的配置。

【解决方案1】：

经验法则：与代码中的iterations 相比，SQL Query 总是更有效。

关于过滤 - 当您过滤 SQL 时，它返回的数据将少于您在应用程序中过滤时返回的数据。另外我认为query 中的过滤器比code 中的过滤器更快。

【讨论】：

【解决方案2】：

因此，建议保存在数据库中。数据应该在数据库中，逻辑应该在代码中。在您的情况下，条件是提供数据，这些数据会发生变化。但逻辑保持不变。

希望我很清楚。

【讨论】：

【解决方案3】：

您的奖品表未标准化。我看到与 Condition 的一对多关系。

当你这样做时，你的过滤器是一个 Join 而不是更复杂的 WHERE 子句。

无论哪种情况，我认为这最好由数据库完成。您需要注意处理主键。如果您的查询没有正确编入索引，它们的性能将会很差。

【讨论】：