我正在构建一个包含大量潜在输入的复杂搜索应用程序。每个输入都是可选的。我正在尝试以模块化方式构建查询。
假设我有两个不同的查询,每个查询都有独立的WHERE
条件:
SELECT * FROM t1 WHERE t1.c1 = x
SELECT * FROM t2 WHERE t2.c1 = y
我发现以下代码有效:
SELECT * FROM t1 INNER JOIN t2 ON t1.c2 = t2.c2 WHERE t1.c1= x AND t2.c1= y
然而,由于WHERE
条件最终被组合在一起,因此以模块化方式实现它将非常困难。所以,我试过这个:
SELECT * FROM t1 WHERE t1.c1 = x INNER JOIN ON t1.c2 = t2.c2 WHERE t2.c1 = y
但是,此代码无效。使用独立WHERE
子句加入任意数量的表的最佳方法是什么?
答案 0 :(得分:0)
在这种情况下,我在代码中动态构建WHERE子句。我不确定是否有更好的方法。
请务必使用prepared statements(参数化查询)。构建不带参数的WHERE子句是huge security issue。
答案 1 :(得分:0)
表之间的连接可以有条件地实现 - 并且where
子句在最后连接 - 如下所示:
SELECT *
FROM t1
INNER JOIN t2 ON t1.c2 = t2.c2
INNER JOIN t3 ON t1.c3 = t3.c3
INNER JOIN t4 ON t1.c4 = t4.c4
WHERE t1.c1 = x
AND t2.c2 = y
AND t3.c3 = z
AND t4.c4 = a
您可以根据用户选择的选项有条件地将其构建为字符串。
虽然动态构建where
子句和joins
可能会有效,但可能会有一些陷阱需要注意。
首先,联接仍然可能必须基于表连接在一起的自然方式自定义构建 - 例如,t3
可能只能加入t2
而不能{{1 }}。您对t1
子句有类似的问题。每个where子句都必须根据表中的列自定义构建。
换句话说,这个问题不太可能完全推广。最后,您需要制作依赖于表格细节的自定义SQL。更糟糕的是,随着时间的推移,表格将发生变化,SQL将不得不随之改变。如果要动态构建复杂的SQL,可能会让自己陷入维护问题。
此外,随着您的应用程序的增长,您可能希望调整每个组合的SQL以优化查询。确保在构建时考虑到这一点。