Php 筛选MySQL结果的最佳实践

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

我的问题是： 这些过滤器不仅需要添加smple WHERE子句，还需要一个包含多个联接的大查询。结果查询的行数超过30行

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

你觉得怎么样

问候

如有疑问，这里是表格结构/代码。这不是确切的代码，因为还有一个修订系统，使其更加复杂，但要理解这一点就足够了：

表格提交：

ID (primary)
(additionalColumns)

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

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

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

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

表格报告：

ID (primary)
(additionalColumns)

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

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

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

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

表格报告对象：

ID (primary)
(additionalColumns)

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

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

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

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

表格会计：

ID (primary)
(additionalColumns)

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

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

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

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

表记帐对象：

ID (primary)
(additionalColumns)

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

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

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

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

对于提交，将创建一个或多个报告，其中包含多个要考虑的对象（报告对象）。 对于每个报表，我可以创建多个会计科目，其中每个会计科目针对报表的几个对象。会计报表对象存储在会计报表对象中

---

我的查询/筛选检查，如果submissionID的每个报表对象都有一个submissionID（会计对象存在）。

没有一个明确的答案，在实践中，如果它的工作和运行速度足以满足您的需要，那么您可以保持原样。优化永远是你可以回头做的事情

正确连接 如果只是检查联接表是否存在，并且只包含该联接的结果，则可以通过正确的左/右联接表达式来执行此操作。这总是第一个电话

表现力 使用SQL时也要尽可能地表达，如果您想给它提供优化查询的最佳机会，例如，存在诸如EXISTS之类的关键字，请确保使用它们

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

• 这是绕过计算列引入的慢度的最简单方法

缺点：

• 破坏了你的标准化模式
• 如果在代码中手动执行，您将忘记在某个地方执行，这会导致头痛
• 触发器可能有点痛苦

物化视图 这类似于非规范化，但通过创建存储视图防止污染规范化表。在MySQL中，当值发生变化时，通过将复杂选择的结果存储到结果表中，可以实现这一点。同样，与非规范化一样，复杂性使其保持最新。这通常是通过触发器完成的。这可能是一件痛苦的事情，但却避免了模式的复杂性。如上所述by@eggyal它还不是MySQL支持的功能，所以你必须自己动手。。。

优点：

• 使脏的非规范化内容远离您良好的规范化模式

缺点：

• 不支持物化视图，因此需要进行设置
• 如果在代码中触发视图的刷新，则会得到过时的数据，但不会像反规范化的单列过时那样痛苦
• 触发器可能有点痛苦

如果你不确定，这真的很重要，做一些基准测试

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

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

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

将所有相关查询放在一个位置，即一个以各种形式处理此查询的类或脚本。这样，至少所有更改都限制在一个文件中

为了帮助您自己，您可以对其进行一些重构，以消除查询之间的重复

---

此外，如果您觉得数据库信息过于暴露于代码中，您可能希望将其抽象到视图后面

使用视图或（甚至）物化视图怎么样？如果我们能看到SQL语句和/或模式，我们可以帮助您@YohanesGultom+1表示物化视图。。。通常情况下，这类问题的答案是。@StuartWakefield:问题被标记了，这是。@eggyal开箱即用，我同意，尽管在实践中你仍然可以实现物化视图。我在上面的帖子中添加了我的表结构。希望这有助于//编辑：更新了结构，会计对象中的小错误谢谢你的回答！目前，性能并不重要，不会有那么多用户同时使用该系统。我只是想知道这里的好习惯是什么。如果我将查询保持原样，那么If将以稍微定制的方式在我的项目中位于3-4个位置（计算分页的筛选对象、查询筛选对象、带筛选的高级搜索等）。这意味着，如果我做了任何更改，我必须确保所有查询都已更新。正如我在第一篇文章中所说的，表的结构相当复杂，所以维护并不是那么容易。谢谢你添加了赞成和反对意见。非规范化是我一直在寻找的关键词。我想我会去去规范化这些东西。在我的情况下，这将比维持美国的稳定更为痛苦