1

这是我在此处发布的另一个问题。请不要关闭为重复，因为它走向另一个方向。

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

T_RIDER
  RIDER_ID
  TMP_PONYLIST
  ...

T_RIDER_PONY
  RIDER_ID
  PONY_ID

T_PONY
  PONY_ID
  PONY_NAME
  ...

T_RIDER并T_PONY通过 建立n:m关系T_RIDER_PONY。 T_RIDER并T_PONY有更多的列，但只有TMP_PONYLIST在PONY_NAME这里相关。

TMP_PONYLIST是一个分号分隔的列表PONY_NAMES，想象一下"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 
  ...

对于... 我尝试了本文中的以下聚合技术。

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

我还没试过：

  • 具体功能
  • 使用 Ref 游标的函数泛型函数
  • 收集功能

您是否看到任何机会让这些中的任何一个与物化视图一起工作，或者它是否毫无意义。你知道其他可能适用于物化视图的技术吗？

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

4

1 回答 1

2

你想创建一个 ON COMMIT REFRESH JOIN AGGREGATE MATERIALIZED VIEW。这种类型的MV有很多限制。基本上，除了简单的连接、SUM、COUNT 和 AVG 之外，所有 DML 活动都不会在提交时刷新。

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

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

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

于 2009-11-13T15:09:18.233 回答