在应用程序中处理自然 JOINed 结果的良好实践答案

【问题标题】：Good practice for handling naturally JOINed results across an application在应用程序中处理自然 JOINed 结果的良好实践
【发布时间】：2015-08-21 01:15:09
【问题描述】：

我正在开发一个现有应用程序，该应用程序使用一些 JOIN 语句来创建“不可变”对象（即，始终将结果连接起来以创建可处理的对象 - 仅来自一个表的结果将毫无意义）。

例如：

SELECT r.*,u.user_username,u.user_pic FROM articles r INNER JOIN users u ON u.user_id=r.article_author WHERE ...

将产生一个类型的结果，比如ArticleWithUser，这是显示带有作者详细信息的文章（如博客文章）所必需的。

现在，我需要创建一个表featured_items，其中包含列item_type（文章、文件、评论等）和item_id（文章、文件或评论的ID），并查询它以获取某种类型的特色项目的列表。

假设articles 以外的表包含不需要与其他表连接的整个对象，我可以简单地使用动态生成的查询来拉取它们，例如

SELECT some_table.* FROM featured_items RIGHT JOIN some_table ON some_table.id = featured_items.item_id WHERE featured_items.type = X

但是如果我需要从上述类型ArticleWithUser 中获取特色项目怎么办？我不能使用动态生成的查询，因为语法不适合两个 JOIN。

所以，我的问题是：有没有更好的做法来检索总是组合在一起的结果？也许在应用程序端进行第二次 JOIN？

或者我是否必须为每种组合结果类型编写特殊代码？

谢谢！

【问题讨论】：

当然，如果mysql不能handle它，那么将你的不可变与中间件一起猛击。 Handle 被定义为 mysql 中可能发生的事情，包括你不知道的事情。
Mysql 绝对可以处理它，但是查询太临时了（至少 2 个 JOIN，显式命名字段等）。我正在寻找一种更易于维护的解决方案，该解决方案将尽可能接近将 JOINed 表视为单个表。
喜欢一个视图。看看：>

标签： php mysql database join database-design

【解决方案1】：

对于胆小的人来说，视图就像一张桌子。

https://dev.mysql.com/doc/refman/5.0/en/create-view.html

视图可以合并joins。和other views。请记住，在创建时，它们会在基础表上拍摄当时存在的列的快照，因此Alter Table stmts 将列添加到这些表是 not 在 select * 中选取的。

【讨论】：

是的！正是我想要的。谢谢你。视图是否被广泛使用？如果没有，有什么原因吗？这是我第一次遇到他们。
它们在 imo 中被大量使用。其他人可以提供他们的经验。我们会将它们用于系统中的利益相关者（通常是非技术人员）。这样的偷窥者对进行连接、编写报告并不感到兴奋，并且将它们放在一起会是他们在会议上脸上的鸡蛋。所以他们乞求意见。此外，技术人员有点厌倦了做同样的事情而需要稍作修改。那种东西

【解决方案2】：

我认为需要阅读有关 MySQL 视图主题的一篇旧文章： By Peter Zaitsev

要回答您关于它们是否被广泛使用的问题，它们是数据库开发人员工具包的主要部分，并且在某些情况下提供了显着的好处，这与索引而不是视图的性质有关，本身。

【讨论】：

这篇文章很有趣，但是： - 自 2007 年以来的 8 年里，这没有改变吗？ - 那么视图应该如何优化呢？它没有说。