Database 直接从表中选择和查看的区别

直接从表中选择数据与从视图中选择数据有什么区别？

---

每个视图的最佳用途是什么？

在大多数数据库中，它们在功能上是可互换的（不管具体化视图如何，它们完全不同）。创建视图有两个常见原因。1.抽象（和列别名）机制，以及2。用于权限和访问控制。但说到效率，这不是问题。

这样想：

视图只是存在于服务器上并由SQL引擎编译的select语句

通常使用视图来限制/简化表中的结果

问候

---

它取决于数据库和视图的定义

为列添加别名或执行简单计算的简单视图与直接进行查询没有什么不同

但是，在某些情况下，视图的速度可能会慢得多。例如：在Oracle中，如果嵌套视图查询过多（例如，一个视图使用另一个视图作为表，而另一个视图使用另一个视图等），则可能会产生糟糕的性能

---

一般来说，您需要使用特定的数据库和查询进行测试。

根据Microsoft的说法，如果您在sql server 2000/2005/2008中使用索引的视图，将有助于提高性能

索引视图可以通过以下方式提高查询性能
1.聚合可以预计算并存储在索引中，以最大限度地减少查询执行期间的昂贵计算。
2.可以预联接表并存储结果数据集。
3.可以存储联接或聚合的组合

但就像表上的索引一样，视图上的索引也会经历修改开销。因此，只有在视图运行时速度提高的好处超过了更新视图索引所需的时间时，才向视图添加索引

下面的链接提供了更多信息（关于何时使用what）

---

不是真的。某些数据库在嵌套视图时存在性能问题。您有任何引用吗？这似乎不太可能，（尽管这就是为什么我说“在大多数数据库中”。）是的。在Oracle中，嵌套视图可能表现不好。在比较扩展查询与Oracle内部定义为多个视图的相同查询时，我们自己也经历过这种情况。我很感兴趣，也很惊讶，看看我们是否能得到任何佐证。这将是对任何商业DBMS产品的毁灭性指控。您是否声称使用视图会使查询比它所代表的内联子选择慢？如果效率低下，我敢打赌这是因为视图不适当地添加了比需要的更多的字段和/或联接。但它的性能仍然与等效的单个SQL语句相同。不，我们尝试过使用相同的查询，只是在视图中或在带有子查询的选择中使用。后者可以快得多。为什么？不知道，甲骨文充满了神秘感，而且不是一种好的方式。不，我不是说视图自动变慢；事实上，它们通常更快，只是因为它们是预编译的。但不幸的是，现实与具有复杂视图的理论并不相同。如果你仔细阅读这篇文章，你会发现它谈论的是“物化视图”，这实际上是另一种动物，它真正创造了一种特殊形式的表。