什么时候应该在实际的表上实际使用视图?我应该期望这会产生什么好处?
总而言之,使用视图而不是表的优点是什么?难道我不应该首先按照视图应该的样子来设计表吗?
发布于 2010-12-07 23:23:06
当您需要确保每次都遵循复杂的逻辑时,视图是可以接受的。例如,我们有一个视图,它创建所有财务报告所需的原始数据。通过让所有报告都使用此视图,每个人都在使用相同的数据集,而不是一个报告使用一组连接,而另一个报告忘记使用一个给出不同结果的连接。
当您想要将用户限制为特定的数据子集时,视图是可以接受的。例如,如果不删除记录,而只是将当前记录标记为活动记录,而将旧版本标记为非活动记录,则希望使用视图仅选择活动记录。这可以防止人们忘记在查询中放置where子句,从而得到不好的结果。
视图可用于确保用户只能访问一组记录-例如,特定客户端的表的视图,而没有表的安全权限可能意味着该客户端的用户只能看到该客户端的数据。
在重构数据库时,视图非常有用。
当您使用视图调用视图时,视图是不可接受的,这可能会导致糟糕的性能(至少在SQL Server中是如此)。我们几乎失去了一个价值数百万美元的客户,因为有人选择以这种方式抽象数据库,性能非常糟糕,超时频繁。我们也必须支付修复费用,而不是客户,因为性能问题完全是我们的错。当视图调用视图时,它们必须完全生成底层视图。我见过这样的情况,视图调用视图,视图调用视图,生成了数百万条记录,以查看用户最终需要的三条记录。我记得其中一个视图花了8分钟对记录进行简单的计数(*)。视图调用视图是一个非常糟糕的想法。
视图通常不适合用来更新记录,因为通常您只能更新同一个表中的字段(同样,这是SQL Server,其他数据库可能会有所不同)。如果是这样的话,直接更新表更有意义,这样您就可以知道哪些字段是可用的。
发布于 2010-12-07 23:06:45
一种常见的做法是在视图中隐藏联接,以便向用户呈现更加非规范化的数据模型。其他用途涉及安全性(例如,通过隐藏某些列和/或行)或性能(在物化视图的情况下)
发布于 2010-12-07 23:24:55
您应该在设计表时不考虑视图。
除了保存联接和条件外,视图还具有性能优势: SQL Server可以在视图中计算和保存其执行计划,因此比“动态”SQL语句更快。
视图还可以简化您在字段级别进行用户访问的工作。
https://stackoverflow.com/questions/4378068
复制相似问题