当前位置：文江博客话题详情

有没有理由不在 Oracle 中使用视图？

发布于 2024-11-23 15:41:18 字数 238 浏览 3 评论 0原文

我最近注意到我的公司（而且是一家大公司）没有人使用视图。

我想创建一些视图主要是因为它们使我的查询看起来更简单，并且这些视图位于不太频繁更新的表上（每天一次）。

我的替代方案是创建一个记录类型的类型表，并在每次调用 SP 时填充它。这比使用视图更好吗？（我的猜测是否定的）

PS：数据库是oracle 10g并且编辑： - 是的，我到处打听，但没有人能给我一个理由。 - 视图和使用它们的查询都依赖于连接。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

執念 2024-11-30 15:41:18

当存在性能影响时，美学在 SQL 或一般编码中没有一席之地。

如果优化器确定可以发生谓词推送，则视图将与直接查询视图表示的表一样好。正如 Justin 提到的，因为视图是一个扩展为视图所代表的底层查询的宏，所以很可能会进行软解析（重新使用缓存中的查询），因为缓存检查需要精确匹配查询。

但请注意以下几点：

分层视图（一个视图基于另一个视图）是一种不好的做法 - 在视图运行之前不会遇到错误将
视图连接到其他表和/或视图是高度可疑的 - 优化器可能不会如果基础查询代替了视图引用，也能看到一些东西。我有过这样的经历，因为加入的视图所做的事情超出了查询所需的范围——有时，来自所有使用的视图的查询被压缩为一个运行得更好的查询。

我建议创建您的视图，并比较 EXPLAIN 计划，以确保您至少获得相同的性能。在评论该方法之前，我需要查看您用于填充类型的代码，但它本质上听起来像派生表...

您可能会从使用物化视图中受益，但众所周知，它们在支持的内容方面受到限制。

回复收藏 0 原文

只是一片海 2024-11-30 15:41:18

在这种情况下，听起来创建一些视图确实会有帮助。

您是否询问过周围的人，看看为什么没有人使用视图？这看起来很奇怪，并且肯定表明您没有非常有效地重用 SQL。如果没有视图，您可能会倾向于将相同的逻辑放在许多不同的 SQL 语句中，而不是放在单个视图中，这会使维护变得很痛苦。

回复收藏 0 原文

那小子欠揍 2024-11-30 15:41:18

不使用可能有效或无效的视图的一个原因是它们有可能在没有任何视图的情况下创建复杂性

例如我可以写

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
         .....

现在我只需要部署、维护和版本控制单个对象。

如果仅存在于一个上下文中，则维护两个单独的对象会产生不必要的负担。此外，部署后的任何更改都需要评估依赖于 UseFoo 的内容。当两个对象需要访问对 UseFoo 和 Foo 进行评估的任何对象时，

当然，另一方面，如果 Foo 表示一些共享逻辑，则评估是无论如何都需要，但您只需查找并更改一个对象。

One reason not to use views which may or may not be valid... is that they have the potential to create complexity where there isn't any

For example I could write

CREATE VIEW foo as <SOME COMPLEX QUERY>

then later I could write

CREATE Procedure UseFoo as 
BEGIN
       SELECT 
          somefields
       FROM
          x 
          INNER JOIN foo
         .....

So now I'm creating to objects that need to be deployed, maintained, version controlled etc...

Or I could write either

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
         .....

And now I only need to deploy, maintain, and version control a single object.

If <SOME COMPLEX QUERY> only exists in one context maintaining two separate objects creates an unnecessary burden. Also after deployment any changes to requires evaluating things that rely on UseFoo. When two object you need to visit anything that evaluating on UseFoo and Foo

Of course on the other hand if Foo represents some shared logic the evaluation is required anyway but you only have to find and change a single object.

回复收藏 0 原文