物化視圖與列聚合

這是另一個刺我陷入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

物化視圖與列聚合

回答

相關問題