一组类似Oracle功能的优化选项

我有三个自定义函数，它们做着非常相似的事情：它们从同一个相当复杂的联接集中提取不同的数据—生成联接表需要花费时间—并且通常都在同一个select中调用。这显然是低效的，我想提高性能，但最好的方法是什么

创建一个包含所有参数的复杂连接的实体化视图，并在每个函数中引用它，或者干脆省略函数。 将这三个函数一起滚动，并以自定义类型一次返回所有值。 还有别的吗？

---

对于我这样的新手来说，第一个选择似乎是最好的解决方案；但它显然有一个缺点，就是创建了一个相当大的实体化视图，这需要维护，因此需要根据需要进行刷新；虽然这部MV在其他地方可能有用。。。第二种选择是有点老套；但是还有什么我没有考虑的吗？

老实说，我会选择选项2，除非你真的想要一个具体化的观点。您可以将函数强制转换为一个表，这样您就可以正常地从中进行选择。

我希望完全忽略这些函数，并重新编写查询，以便不使用函数。任何选择数据的函数，尤其是使用复杂联接的函数，都是减慢查询速度的可靠方法，因为该函数必须为处理的每一行执行一次，甚至不必由主查询返回，可能执行1000或100000次

注意，它必须是一个具体化的观点；如果它是一个常规视图，那么它可能会在每次需要时执行，这也是同样的问题。你能发布一个这些函数的示例吗？@Tony:我不确定公开我的函数是否很酷；但勇气涉及到一个大的选择，这是相当简单的保存块，这是低效率的根源。考虑到with部件是如此透明，它非常适合移动到MV中。这是我选择的选项，因为实体化视图将有效地总结数据库中大约0.5GB大小的最大表，可能还有第二大表。。。那不行！。。。将三个函数合并为一个函数将查询的运行时间从17秒减少到6秒。Yay：虽然它确实显示了这些函数调用有多慢。我们假设线性-这不是一个好的假设，但不要紧-然后，假设也调用函数的基本查询在时间x中运行，该函数在y:x+y=6和x+3y=17中运行；因此，基本查询的运行时间为0.5秒，函数的执行时间为5.5秒，也就是说，长一个数量级：PinDect。。。我的项目是创建一个抽象层，因为所需的查询对于其他人来说太复杂了，例如在报告中。函数似乎是最好的解决方案；尽管如此，在这种情况下，性能会受到影响。那么使用视图来隐藏复杂性呢？我想这主要是出于一致性。我在任何地方都使用过函数——大多数情况下，没有这种问题——来免除最终用户对模式的了解，即编写连接所需的知识，甚至使用视图来简化事情。我明白了。好吧，SQL并不是真正为最终用户准备的：他们更喜欢你点击的东西！