在Postgres中使用物化视图的最佳实践

Question

作为背景，我使用了许多基于PostGIS空间查询的物化视图，其中一些视图需要几天才能刷新(每当底层空间数据(即道路网络)更新时，这些视图很少刷新)。然后，我有许多其他的观点，依赖于这些物化的观点。

虽然在一般情况下使用物化视图很好，但当我需要更改其中一个视图的定义(例如，更改联接条件或添加新列)时，这将成为一场噩梦。由于没有类似于物化视图的CREATE OR REPLACE ...，我最终不得不删除并重新创建所有依赖对象。

最近，我开始在标准视图中“包装”我所有的物化视图，作为解决这个问题的一种方法。因此，基本上每个物化视图都有一个相应的标准视图，它直接从物化视图中选择所有列。然后，没有依赖者直接引用物化视图，他们只引用包装视图。这允许我暂时替换包装器的定义，以指向不同的数据源(而不是物化视图)，这样我就可以修改物化视图的定义，最后将包装器重新定向回物化视图。呼！它可以工作，并且避免了级联拖放/重新创建对象进程的需要，但仍然显得非常笨重。

是否有一个最佳实践过程来使用物化的视图来克服这些限制？这里通常采用什么方法来避免级联删除/重新创建步骤？

Answer 1

虽然在一般情况下使用物化视图很好，但当我需要更改其中一个视图的定义(例如，更改联接条件或添加新列)时，这将成为一场噩梦。

其中一个想法是将它们放在相同的模式中，例如foo_matviews或foo_cache，然后创建一个完全删除模式的脚本(使用CASCADE)，然后重新初始化模式和所有内部mat视图。

老实说，它一直运作的如此好，我一直有点困惑，为什么这是一个问题，对任何人。我的代码中总是有几个SQL脚本可以执行类似的操作。我甚至从未需要过像立交桥这样的模式迁移工具这样复杂的工具。

也就是说，在模式中包含了所有这些内容之后，如果愿意，您可以使用创建一个扩展。