我曾与一位禁止使用SQL视图的架构师合作过.他的主要原因是观点使得一个没有思想的编码人员很容易不必要地参与联合表格,如果那个编码人员更加努力,可以完全避免.隐含地,他通过复制粘贴而不是视图中的封装来鼓励代码重用.
该数据库有近600个表并且高度标准化,因此大多数有用的SQL都必须冗长.
几年之后,我可以看到禁令至少有一个不好的结果 - 我们有数百个密集,冗长的存储过程,这些过程无法维持.
事后我会说这是一个糟糕的决定,但你对SQL视图的体验是什么？你发现它们对性能有害吗？关于它们何时适合或不适合的任何其他想法？
Guy*_*uck 31
观点有一些很好的用途; 我已经将它们用于调整和暴露较少规范化的信息集,或者将多个选择的UNION结果用于单个结果集.
显然,任何编程工具都可能被错误地使用,但我无法想到在我的经验中,从性能角度来看,调整不佳的视图会带来任何缺点,并且通过提供明确调整的选择并避免它们可以提供的价值复杂的SQL代码重复可能很重要.
顺便说一句,我从未成为建筑"规则"的粉丝,这些规则基于防止开发人员伤害自己.这些规则经常会产生意想不到的副作用 - 我工作的最后一个地方不允许在数据库中使用NULL,因为开发人员可能忘记检查null.这最终迫使我们解决"1/1/1900"日期和整数在所有针对数据库构建的软件中的默认值为"0",并引入了一些由devs工作引起的错误,这些错误在NULL是适当的值的地方工作.
HLG*_*GEM 17
不是观点的忠实粉丝(不记得我最后一次写过一篇观点)但也不会完全禁止它们.如果您的数据库允许您在视图上放置索引而不仅仅是在表上,那么通常可以提高性能,从而使它们更好.如果您正在使用视图,请务必查看索引.
我真的只看到对分区数据和对应用程序非常关键的极其复杂的连接的视图的需求(考虑这里的财务报告,从同一数据集开始,一切都可能是关键的).我知道一些报告工具似乎更喜欢存储过程的视图.
我支持永远不会返回比特定实例更多的记录或字段,并且过度使用视图往往会使人们返回更多字段(并且过多的情况下,连接数太多)而不是浪费系统资源.
我也倾向于看到依赖于视图的人(不是视图的开发者 - 只使用它们的人)通常不能很好地理解数据库(因此如果不使用视图,他们会得到连接错误)和对我来说,对数据库编写好的代码至关重要.我希望人们了解他们要求数据库做什么,而不是依靠一些魔法黑盒子的视图.这当然是个人观点,您的里程可能会有所不同.
像BlaM一样,我个人没有发现它们比存储过程更容易维护.
2010年10月编辑补充:自从我开始写这篇文章以来,我有机会使用由沉迷于使用视图的人设计的几个数据库.更糟糕的是,他们使用调用视图调用视图的视图(最终我们达到了可以调用的表数量的极限).这是一场表演噩梦.在一个视图中获取记录的简单计数(*)需要8分钟,并且获取数据的时间要长得多.如果您使用视图,请务必使用调用其他视图的视图.您将构建一个很可能无法在正常的生产性能负载下工作的系统.在SQL Server中,您只能索引不调用其他视图的视图,因此当您在链中使用视图时会发生什么,是必须为每个视图构建整个记录集,直到你到达最后一个视图集时才应用where子句标准.您可能需要生成数百万条记录才能看到三条记录.当您真正只需要加入一次时,您可以连接到同一个表6次,您可能会返回比最终结果集中所需的列多很多的列.
我当前的数据库完全充斥着无数小表,每个表不超过5行.好吧,我可以算一下,但它很杂乱.这些表只是保持常量类型值(想想枚举),并且可以很容易地组合成一个表.然后,我创建了模拟我删除的每个表的视图,以确保后向可压缩性.工作得很好.
| 归档时间： |
|
| 查看次数： |
6184 次 |
| 最近记录： |