规范化表、SQL 连接和视图答案

【问题标题】：Normalised tables, SQL Joins and Views规范化表、SQL 连接和视图
【发布时间】：2013-07-03 17:42:18
【问题描述】：

我正在创建一个预订应用程序，并已尽可能标准化数据库。我的问题如下，在对 WHERE 子句中的组合视图进行选择性选择之前，我应该在数据库中创建再次组合表的视图，还是在将表加入视图之前使用选择过滤表更好？

编辑：包含的示例。

第一个场景先创建组合视图，然后对组合视图执行SELECT（这个视图可能有上千条记录）：

CREATE VIEW appc as 
SELECT * FROM appointment
LEFT OUTER JOIN chair
ON appointment.chair_idchair = chair.idchair

SELECT * FROM appc
WHERE chair_idchair = 1;

第二种情况会先过滤连接左边的表，然后根据过滤后的表创建一个视图，然后使用这个小得多的视图进行连接：

CREATE VIEW appf as 
SELECT * FROM appointment
WHERE chair_idchair = 1;

SELECT * FROM appf
LEFT OUTER JOIN chair
ON appf.chair_idchair = chair.idchair

【问题讨论】：

你能举例说明你想到的两种不同风格吗？

标签： mysql sql

【解决方案1】：

这对 MySQL 几乎没有影响。 MySQL（与其他一些 RDBMS 品牌不同）不会在视图本身中存储任何内容。把 MySQL 视图想象成一个宏。在大多数情况下，查询视图与执行您定义为视图的查询完全相同。

在查询视图时在 WHERE 子句中应用后续条件与视图的查询非常透明地结合在一起，就好像您已经编写了完整的查询并给了它一个额外的条件。

例外：您可以选择使用ALGORITHM=TEMPTABLE 创建视图，强制它将视图的结果存储在临时表中，然后应用您在查询中指定的额外条件。在这种情况下，最好将条件构建到视图的查询中，以减小生成的临时表的大小。

【讨论】：

谢谢比尔，我现在明白了。

【解决方案2】：

作为一般规则，优化器非常聪明，可以在构建查询计划时直接查看视图。如果您尝试通过预先选择一些数据来“帮助”优化器，您可能会向优化器隐藏信息，这些信息本来可以让优化器创建更智能、更优化的计划。

【讨论】：