具有列聚合的物化视图

Question

这是我发布here问题的另一个问题。请不要复制， 因为它走向另一个方向。

我想使用另一列的聚合自动更新数据库列。 涉及三个表：

T_RIDER
  RIDER_ID
  TMP_PONYLIST
  ...

T_RIDER_PONY
  RIDER_ID
  PONY_ID

T_PONY
  PONY_ID
  PONY_NAME
  ...

T_RIDER和T_PONY通过T_RIDER_PONY建立了 n：m 关系。 T_RIDER和T_PONY有更多列，但此处只有TMP_PONYLIST和PONY_NAME。

TMP_PONYLIST是PONY_NAMES的分号spararated列表，想象"Twisty Tail;Candy Cane;Lucky Leaf"之类的内容。 无论T_RIDER_PONY或T_PONY发生什么情况，我都希望保持此字段为最新状态。

所有应用程序仅适用于视图，从不直接访问表，我需要使用物化视图解决此问题。物化是绝对必要的 由于性能原因，并且需要视图在提交时自行更新。

应该像这样创建视图

CREATE MATERIALIZED VIEW
  V_TMP_PONYLIST 
BUILD IMMEDIATE
REFRESH COMPLETE ON COMMIT
AS SELECT 
  ...

For ...我尝试了this article中的以下聚合技术。

• WM_CONCAT - ＆gt;在我的Oracle中不可用
• 用户定义的聚合 - ＆gt; ORA-12054
• ROW_NUMBER和SYS_CONNECT_BY_PATH - ＆gt; ORA-12054

我还没试过：

• 特定功能
• 使用Ref Cursor的函数通用函数
• 收集功能

你是否认为有任何机会使用物化视图，或者没有意义。您是否了解可能适用于物化视图的其他技术？

我正在使用Oracle数据库10g企业版10.2.0.4.0 - 64位。

Answer 1

您要创建一个ON COMMIT REFRESH JOIN AGGREGATE MATERIALIZED VIEW。这种类型的MV有lots of limitations。基本上除了简单连接之外的任何东西，SUM，COUNT和AVG都不会在所有DML活动中都是ON COMMIT-refreshable。

在我看来，你试图以错误的心态解决这个问题：你已经选择了技术路径之前知道它是否能在物理上解决你的问题。您应该学习所有可用的工具，并选择能满足您要求的最佳工具（最容易实施/维护）。

您已经获得了已知可行的选项：复杂逻辑触发器，简单视图，过程方法（仅通过经过全面测试和批准的API来更新基表，这些API已知可以很好地处理列逻辑）。 / p>

您已经声明，由于性能问题，简单视图无效。我建议研究其他选项：触发器将让你保留现有的代码，但你可能会有很多不可预见的副作用（复杂的触发很有趣）。程序逻辑是最容易编码/维护的，但您必须实际使用它并修改您的应用程序才能使用新的API。您可能必须撤消更新基表的权限，以确保通过API更新表。