过滤 MySQL 结果的最佳实践

Question

我想在我的 PHP 项目中实现一个过滤器功能。为了实现过滤器，我通常只在我的查询中添加一个 WHERE 子句来显示过滤的结果。

我的问题是：这些过滤器不仅需要添加一个简单的 WHERE 子句，还需要一个包含多个 JOIN的巨大查询。结果查询有 > 30 行。

稍后，还应该有一个搜索功能，然后也需要这个巨大的查询。我想知道这是否是一个好的做法，或者我是否应该在我的数据库表中添加一个“冗余”数据库列，在那里我计算每次更新时过滤所需的属性。有了这个专栏，我就不会对我的项目的不同地方进行大量查询，而是有一个多余的专栏。

你怎么认为？

你好

正如所质疑的，这里是表结构/代码。这不是确切的代码，因为还有一个修订系统使它变得更加复杂，但对于理解这已经足够了：

表格提交：

ID (primary)
(additionalColumns)

表格报告：

ID (primary)
submissionID (reference to submission table)
(additionalColumns)

表report_objects：

reportID (reference to reports table, multiple report_object for one report)

表记账：

ID (primary)
reportID (reference to reports table, multiple accountings for one report)
(additionalColumns)

表accounting_objects：

ID
accountingID (reference to accounting table, multiple accounting_object for one accounting)
(additionalColumns)

对于提交，正在创建一个或多个报告，其中包含多个对象 (report_objects)。对于每个报表，我可以创建多个记帐，其中每个记帐针对报表的几个对象。会计报表对象存储在accounting_object

我的查询/过滤器会检查一个 submitID 的每个 report_object 是否都针对一个 submitID 进行了计算（accounting_object 存在）。

Answer 1

没有一个明确的答案，在实践中，如果它可以工作并且运行得足够快以满足您的需求，那么您可以保持原样。优化始终是您可以回头进行的事情。

正确加入

如果您只是检查连接表是否存在并且仅包含该连接的结果，则可以通过正确的 LEFT / RIGHT JOIN 表达式来完成此操作。这始终是第一个电话。

表现力

还要尽可能地使用 SQL 来表达，您希望给它最好的机会来优化您的查询，例如，有诸如 EXISTS 之类的关键字，请确保使用它们。

非规范化

您可以添加存储计算值的列，由此产生的复杂性是确保该值始终是最新的。这可以通过触发器或手动完成。优点：

• 这是解决计算列带来的缓慢问题的最简单方法。

缺点：

• 破坏了你良好的规范化模式
• 如果您在代码中手动执行此操作，您会忘记在某个地方执行此操作，从而导致头痛。
• 触发因素可能会有点痛苦。

物化视图

这类似于非规范化，但通过创建存储视图来防止污染规范化表。在 MySQL 中，这是通过在值更改时将复杂选择的结果存储到结果表中来实现的。同样，与非规范化相同，复杂性在于保持最新状态。它通常是通过触发器完成的。这可能会很痛苦，但可以避免架构的复杂性。正如 @eggyal 所提到的，它还不是 MySQL 所支持的功能，因此您必须 DIY... MySQL 的物化视图

优点：

• 让脏的非规范化内容远离你好的规范化模式。

缺点：

• 不支持物化视图，因此设置它们需要工作。
• 如果您在代码中触发视图刷新，您会得到陈旧的数据，但并不像非规范化的单列陈旧那么痛苦。
• 触发因素可能会有点痛苦。

如果您不确定（这确实很重要），请进行一些基准测试。

编辑如果您的代码在代码库中以一种或另一种形式编写了此查询，那么将来可能会引起麻烦，因为如果或当它们发生变化时，您将必须记住更改所有位置的语句。

如果通过执行上述操作，您的陈述变得非常简单和简洁，那么它们之间可能存在足够的差异，因此不会成为问题。

您可以做一些事情来帮助您：

1. 将所有相关查询放在一个位置，即以各种形式处理该查询的单个类或脚本。这样一来，至少所有更改都仅限于一个文件。
2. 为了帮助自己解决更多问题，您可以对其进行一些重构以消除查询之间的重复。

另外，如果您觉得数据库信息过于暴露于代码，您可能需要将其抽象到视图后面。