我有一个从基表创建的视图。这个视图基本上是没有任何过滤条件的表的精确副本，它包含表的所有列和记录。
在我的应用程序或存储过程中直接使用视图（表的直接副本）代替表是否有任何优势。
答案 0 :(得分：3)
但是你需要注意视图的工作方式有点不同，因为你最终在数据库方面有些过分。
视图的工作方式是，执行Select *，然后对要添加到其中的列进行过滤。
除非出现一些严重的安全问题，否则我会非常厌倦使用这些视图。
要做的就是创建一个直接从表中获取数据的存储过程。这样，您可以获取索引的最大值以及所有这些。
干杯
答案 1 :(得分：2)
一个优点（或缺点，取决于您的观点）是，Views允许您在SQL服务器中而不是在代码中存储业务逻辑。如果您需要轻松更改业务而无需重新编译代码，则修改视图是一种快速简便的方法。
我个人更喜欢在代码中定义应用程序的业务逻辑：）
答案 2 :(得分：0)
在这种情况下，视图和表之间没有区别。 view不是表的副本，而是存储的select语句。
答案 3 :(得分：0)
从性能方面来看，这种方法可能存在严重的缺点。
http://www.sql-server-performance.com/tips/views_general_p1.aspx
我建议尽可能避免使用视图。
答案 4 :(得分：0)
不。
除索引视图外，视图仅对使SQL清理读取非常有用 - 执行包含视图的查询与执行查询并将视图定义复制并粘贴到查询中基本相同。
我不鼓励以这种方式使用复杂视图，因为尽管它使查询看起来更清晰，但它使诊断过程更加困难（因为您需要查找所有视图以了解原始查询是什么做）
答案 5 :(得分：0)
可能没有直接的目的或好处，但它确实为您提供了一个抽象点，可以在以后的某个时间点提供基于架构或安全性的好处。
该视图本质上可以被视为数据契约，在未来允许基础结构灵活到一定程度，而外界无法实现它。
在安全方面，在未来的某个时刻可能会插入一个where子句，它开始为您提供行级别过滤/安全性，而对该表的直接访问可防止任何此类未来移动。
答案 6 :(得分：0)
视图可以被认为是物理层（表）顶部的逻辑层在您的情况下，当层太薄时，它的值可能会受到质疑。然而，随着时间的推移，情况可能并非如此。使用视图访问表格，几乎不需要任何费用，但可以使代码与物理模型的可能更改隔离。