1

我们已决定在 Oracle 中的一些常规视图之上分层一些“参数化视图”,以便正确鼓励在查询中始终使用正确的 where 谓词。

大部分重复代码(适当连接的表)将显示在视图中,因此我们将不再拥有许多不同的过程和函数,它们都有自己的通用连接和过滤器副本。

然后我们将在这些视图上分层流水线表函数,以确保调用者提供必要的过滤器,这样视图就不会“在所有时间和空间上”被调用。我已经查看了使用 sys_context 和 userenv 以及包变量的替代方案,尽管它们似乎是 Oracle 用户所称的参数化视图,但它们根本不可行,每次使用视图时都将这些 shims 放在视图周围,并且它们不能在自加入。

我在很多地方读过很多关于这个的内容,包括 StackOverflow:

ORACLE 11g 中的表值函数?(参数化视图)

数据库:流水线函数

是否允许在流水线 PL/SQL 表函数中使用 SELECT?

这是一个架构决策,旨在尝试提高应用程序的可维护性,该应用程序已因大量重复查询而变得庞大。视图会在某种程度上有所帮助,但我担心我们无法对调用者强制执行谓词以阻止他们做愚蠢的事情。

我在 SQL Server 中通过内联表值函数使用这种技术取得了很大的成功,它确实有助于使系统更加连贯,并且更容易跟踪所提议更改的依赖关系和影响,因为有 a) 更少的代码b) 更多的重用和更少的重复。

我有点担心最后一个链接,这似乎暗示如果我要加入其中一个流水线表函数并使用它来更新另一个表,我可能会遇到并发或时间问题。

请分享您使用流水线表函数的经验以及我需要注意什么?另外,如果有更好的选择,也请在您的回答中告诉我?

4

1 回答 1

3

是的,在流水线函数中查询表的时间点行为与直接或通过视图查询表的行为不同,因此需要考虑这一点。也就是说,如果流水线函数正在查询一个不经常更新的表,这通常不是问题。不过,我想不出任何并发或时间问题。

My main problem with providing pipelined functions for developers to use (as opposed to using views), is that they (like some views) may be easily misused. Developers may choose to join the results of one pipelined function to another, resulting in very inefficient queries that cannot take advantage of things like indexes, pushed predicates, and table constraints.

If maintainability is your main problem, then I would prefer views - they can help reduce duplicated code by defining common transformations in one place, and perhaps common joins as well; however even these are too easily misused (e.g. joining to a view, even though it joins to another table that is not required by the original query).

性能和效率,可能是需要注意的事情。为应用程序中的所有 SQL 制定严格的审查制度,以查找编写不佳或不一致的查询。

于 2011-05-13T00:51:39.333 回答