我最近注意到没有人在我公司使用观点(而且它是一家大公司)。
我想创建一些视图很大程度上是因为它们使我的查询更加简单,而且这些视图位于有些大的表上,不会经常更新(每天一次)。
我的另一种方法是创建一个类型为记录的类型表,并在每次调用SP时填充它。这比使用视图更好吗? (我的猜测是否定的)
PS:数据库是oracle 10g和 编辑: - 是的,我已经四处询问,但没有人能给我一个理由。 - 视图和将使用它们的查询都很重要。
答案 0 :(得分:6)
当存在性能影响时,美学在SQL或编码方面没有优势。
如果优化器确定可以发生谓词推送,则视图将与直接查询视图所代表的表一样好。正如Justin所提到的,因为视图是一个扩展到视图所代表的底层查询的宏 - 很可能是一个软解析(从缓存中重用查询),因为缓存检查需要完全匹配查询。
但请注意以下事项:
我建议创建您的视图,并比较EXPLAIN计划,以确保您至少获得相同的性能。在评论方法之前,我需要查看用于填充TYPE的代码,但它本质上听起来像派生表......
您可能会从使用物化视图中受益,但它们在支持的内容方面受到了极大的限制。
答案 1 :(得分:5)
在这种情况下,创建一些视图肯定会有所帮助。
你有没有问过为什么没有人使用观点?这似乎很奇怪,肯定会表明你没有非常有效地重用SQL。如果没有视图,您倾向于在许多不同的SQL语句中使用相同的逻辑,而不是在单个视图中,这会使维护变得困难。
答案 2 :(得分:2)
不使用可能有效或无效的观点的一个原因是,它们有可能在没有任何
的情况下创造复杂性例如我可以写
CREATE VIEW foo as <SOME COMPLEX QUERY>
然后我可以写
CREATE Procedure UseFoo as
BEGIN
SELECT
somefields
FROM
x
INNER JOIN foo
.....
所以现在我正在创建需要部署,维护,版本控制等的对象......
或者我可以写
CREATE Procedure UseFoo as
BEGIN
WITH foo as (<SOME COMPLEX QUERY>)
SELECT
somefields
FROM
x
INNER JOIN foo
.....
或
CREATE Procedure UseFoo as
BEGIN
SELECT
somefields
FROM
x
INNER JOIN <SOME COMPLEX QUERY> foo
.....
现在我只需要部署,维护和控制单个对象。
如果<SOME COMPLEX QUERY>
仅存在于一个上下文中,则维护两个单独的对象会产生不必要的负担。部署之后,任何更改都需要评估依赖UseFoo
的内容。当您需要访问两个对象时,需要访问在UseFoo
和Foo
当然另一方面,如果Foo
表示某些共享逻辑,则无论如何都需要进行评估,但您只需查找并更改单个对象。
答案 3 :(得分:1)
根据我的经验,当您拥有大型/复杂的数据库以及一些复杂的查询而没有视图时,这只是因为用户不知道哪些视图或如何使用它们。一旦我解释了使用视图的好处,大多数人都会使用它们而没有任何问题。
根据您的描述,我只是制作一个视图,而不是一个新表。
答案 4 :(得分:0)
视图非常适合隐藏复杂性 - 如果您的用户可以按原样运行您创建的视图(而不是针对视图编写查询),这很好。
但是视图也会出现性能问题 - 如果您的用户知道如何编写sql,并且他们了解他们正在使用的表,那么让他们继续这样做可能会更好。
还要考虑存储过程不太容易出现(相同)视图的性能问题。
答案 5 :(得分:0)
这里有一篇很好的文章的链接和一个片段,它描述了视图以及如何调整它们以获得更好的性能。
视图的使用
视图对于提供水平或垂直数据子集很有用 从表格(可能出于安全原因);隐藏 查询的复杂性;确保使用完全相同的SQL 整个申请过程;并在n层应用程序中检索 关于相关表格中项目的补充信息......
http://www.smart-soft.co.uk/Oracle/oracle-tuning-part4-vw-use.htm