查询 View 而不是存储过程中的原始表是一个好习惯吗？ (即使 View 没有提供任何不同的数据)
我一直认为这可能是个好主意，因为它是一个额外的抽象层，并且类似于在类函数中使用属性而不是成员变量。
但现在我正在查看由 ASP.NET Membership Provider 创建的存储过程，它们总是直接查询表。
我知道使用 View 不能方便地插入数据，但是如果存储过程只是查询数据，你还应该直接使用表吗？如果是，主要原因是什么？ (性能？)
最佳答案
View 只是一个扩展为外部查询的宏。
如果您的 View 包含多个连接，那么当您连接到其他 View 时，当您在存储过程的 SQL 中实际看到 3 个 JOIN 时，您突然有了 20 或 30 种 JOIN 方式。您还会发现每个查询都是不同的:为什么要为每个查询连接相同的 20 或 30 个表？
通常，除非 View 被索引/物化并且优化器可以使用它，否则没有任何好处。
诸如在被 View 屏蔽的单个表上进行计算的想法应该在计算列中:为什么要继续计算它？对于 View 中多个表的计算，应该对其进行索引。
使用存储过程意味着没有基表访问(所有权链)。
View 有很好的用途，可以避免用户直接访问表，或屏蔽模式更改，或提供一些基本的安全性(例如基于 SUSER_SNAME)，但不是为了性能或理念
关于sql - 在存储过程中使用 View 而不是表？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4907711/