有很多数据库视图可以吗?
我很少(每月/每季度)使用 Microsoft SQL Server 2005 数据库视图生成数百个 Crystal Reports 报告.这些视图是否在我不阅读它们的所有时间都在浪费 CPU 周期和 RAM?我应该改用存储过程、临时表还是短期普通表，因为我很少从视图中读取数据?
I infrequently (monthly/quarterly) generate hundreds of Crystal Reports reports using Microsoft SQL Server 2005 database views. Are those views wasting CPU cycles and RAM during all the time that I am not reading from them? Should I instead use stored procedures, temporary tables, or short-lived normal tables since I rarely read from my views?
我不是 DBA，所以我不知道数据库服务器的幕后情况.
I'm not a DBA so I don't know what's going on behind the scenes inside the database server.
是否有可能有太多的数据库视图?什么是最佳做法?
Is it possible to have too many database views? What's considered best practice?
推荐答案
在大多数情况下，这并不重要.是的，SQL Server 在解析 SELECT * FROM 表时将有更多选择(它必须在系统目录中查找表")，但它为此进行了高度优化，并且只要您有足够的 RAM(现在大多数服务器都有)，您不会注意到 0 和 1,000 次观看之间的差异.
For the most part, it doesn't matter. Yes, SQL Server will have more choices when it parses SELECT * FROM table (it'll have to look in the system catalogs for 'table') but it's highly optimized for that, and provided you have sufficient RAM (most servers nowadays do), you won't notice a difference between 0 and 1,000 views.
但是，从人们的角度来看，试图管理和弄清楚数百个"视图在做什么可能是不可能的，因此其中可能有很多重复的代码.如果嵌入在这些冗余视图中的某些业务规则发生变化会发生什么?
However, from a people-perspective, trying to manage and figure out what "hundreds" of views are doing is probably impossible, so you likely have a lot of duplicated code in there. What happens if some business rules change that are embedded in these redundant views?
views 的主要观点是将业务逻辑封装到一个伪表中(所以你可能有一个 person 表，然后是一个名为active_persons"的视图，它有一些魔力).为每个报告创建视图有点愚蠢，除非每个报告都非常孤立和独特，以至于无法重复使用.
The main point of views is to encapsulate business logic into a pseudo table (so you may have a person table, but then a view called "active_persons" which does some magic). Creating a view for each report is kind of silly unless each report is so isolated and unique that there is no ability to re-use.
相关文章