物化视图与列聚合

这是另一个刺我陷入here的问题。请不要关闭，因为它在另一个方向。物化视图与列聚合

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

T_RIDER 
    RIDER_ID 
    TMP_PONYLIST 
    ... 

T_RIDER_PONY 
    RIDER_ID 
    PONY_ID 

T_PONY 
    PONY_ID 
    PONY_NAME 
    ...

T_RIDER和T_PONY具有N：经由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 
    ...

... ...。我尝试了以下聚集技术从this article创建。

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

我没有尝试尚未：

特定功能
Functi使用REF CURSOR通用功能
Collect函数

你看到任何机会，以获得任何这些与物化视图的工作，或者是毫无意义的。你知道其他可能与物化视图有关的技术吗？

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

来源

2009-11-13 bbuser

要创建ON COMMIT REFRESH JOIN AGGREGATE MATERIALIZED VIEW。这种类型的MV有lots of limitations。基本上，除了简单连接外，SUM，COUNT和AVG都不会在所有DML活动都可以刷新的情况下进行COMMIT。

在我看来，您试图以错误的心态来解决这个问题：您已经在之前选择了技术路径，以了解它是否会在物理上解决您的问题。你应该研究每一种可用的工具，并选择那些能够满足你的需求的工具（最容易实现/维护）。

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

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

来源

2009-11-13 15:09:18

我同意心态的东西。我已经深入地探究触发器（另见我的另一个问题，上面的第一个链接）并排除它们。目前我只能探索物化视图......当我确实知道物化视图不可行时，我只会继续前进。 – bbuser 2009-11-13 15:55:50

无法检查链接，目前Oracle服务器似乎停止运行，但听起来很有趣，谢谢。 – bbuser 2009-11-13 15:59:23

物化视图与列聚合

回答

相关问题