1

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

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

T_RIDER
  RIDER_ID
  TMP_PONYLIST
  ...

T_RIDER_PONY
  RIDER_ID
  PONY_ID

T_PONY
  PONY_ID
  PONY_NAME
  ...

T_RIDERT_PONY通过 建立n:m关系T_RIDER_PONYT_RIDERT_PONY有更多的列,但只有TMP_PONYLISTPONY_NAME这里相关。

TMP_PONYLIST是一个分号分隔的列表PONY_NAMES,想象一下"Twisty Tail;Candy Cane;Lucky Leaf"。无论T_RIDER_PONYT_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 回答