物化視圖

有個項目因為有比較多的查詢匯總，考慮到速度，所以使用了物化視圖。簡單的把用到的給整理了下。先看簡單創建語句： create materialized view mv_materialized_test refresh force on demand start with sysdate next to_date(concat(to_char( sysdate+1,'dd-mm-yyyy'),'10:25:00'),'dd-mm-yyyy hh24:mi:ss') as select * from user_info; --這個物化視圖在每天10：25進行刷新物化視圖也是種視圖。Oracle的物化視圖是包括一個查詢結果的數據庫對像，它是遠程數據的的本地副本，或者用來生成基于數據表求和的匯總表。物化視圖存儲基于遠程表的數據，也可以稱為快照。 物化視圖可以查詢表，視圖和其它的物化視圖。特點： (1) 物化視圖在某種意義上說就是一個物理表(而且不僅僅是一個物理表)，這通過其可以被user_tables查詢出來，而得到確認； (2) 物化視圖也是一種段(segment)，所以其有自己的物理存儲屬性； (3) 物化視圖會占用數據庫磁盤空間，這點從user_segment的查詢結果，可以得到佐證； 創建語句：create materialized view mv_name as select * from table_name 因為物化視圖由于是物理真實存在的，故可以創建索引。創建時生成數據： 分為兩種：build immediate 和 build deferred， build immediate是在創建物化視圖的時候就生成數據。 build deferred則在創建時不生成數據，以后根據需要在生成數據。 如果不指定，則默認為build immediate。刷新模式： 物化視圖有二種刷新模式： 在創建時refresh mode是 on demand 還是 on commit。 on demand 顧名思義，僅在該物化視圖“需要”被刷新了，才進行刷新(REFRESH)，即更新物化視圖，以保證和基表數據的一致性; on commit 提交觸發，一旦基表有了commit，即事務提交，則立刻刷新，立刻更新物化視圖，使得數據和基表一致。一般用這種方法在操作基表時速度會比較慢。 創建物化視圖時未作指定，則Oracle按 on demand 模式來創建。上面說的是刷新的模式，針對于如何刷新，則有三種刷新方法：完全刷新（COMPLETE）： 會刪除表中所有的記錄（如果是單表刷新，可能會采用TRUNCATE的方式），然后根據物化視圖中查詢語句的定義重新生成物化視圖。 快速刷新（FAST）： 采用增量刷新的機制，只將自上次刷新以后對基表進行的所有操作刷新到物化視圖中去。FAST必須創建基于主表的視圖日志。對于增量刷新選項，如果在子查詢中存在分析函數，則物化視圖不起作用。 FORCE方式：這是默認的數據刷新方式。Oracle會自動判斷是否滿足快速刷新的條件，如果滿足則進行快速刷新，否則進行完全刷新。關于快速刷新：Oracle物化視圖的快速刷新機制是通過物化視圖日志完成的。Oracle通過一個物化視圖日志還可以支持多個物化視圖的快速刷新。物化視圖日志根據不同物化視圖的快速刷新的需要，可以建立為ROWID或PRIMARY KEY類型的。還可以選擇是否包括SEQUENCE、INCLUDING NEW VALUES以及指定列的列表。查詢重寫（QueryRewrite）： 包括 enable query rewrite 和 disable query rewrite 兩種。 分別指出創建的物化視圖是否支持查詢重寫。查詢重寫是指當對物化視圖的基表進行查詢時，oracle會自動判斷能否通過查詢物化視圖來得到結果，如果可以，則避免了聚集或連接操作，而直接從已經計算好的物化視圖中讀取數據。 默認為disable query rewrite。語法： create materialized view view_name refresh [fast|complete|force] [ on [commit|demand] | start with (start_time) next (next_time) ] AS subquery;具體操作創建物化視圖需要的權限： grant create materialized view to user_name; 在源表建立物化視圖日志： create materialized view log on test_table tablespace test_space -- 日志空間 with primary key; -- 指定為主鍵類型在目標數據庫上創建MATERIALIZED VIEW： create materialized view mv_materialized_test refresh force on demand start with sysdate next to_date(concat(to_char(sysdate+1,'dd-mm-yyyy'),'10:25:00'),'dd-mm-yyyy hh24:mi:ss') as select * from user_info; --這個物化視圖在每天10：25進行刷新 修改刷新時間： alter materialized view mv_materialized_test refresh force on demand start with sysdate next to_date(concat(to_char(sysdate+1,'dd-mm-yyyy'),' 23:00:00'),'dd-mm-yyyy hh24:mi:ss'); 或 alter materialized view mv_materialized_test refresh force on demand start with sysdate next trunc(sysdate,'dd')+1+1/24; -- 每天1點刷新 建立索引： create index IDX_MMT_IU_TEST on mv_materialized_test(ID,UNAME) tablespace test_space; 刪除物化視圖及日志： drop materialized view log on test_table; --刪除物化視圖日志： drop materialized view mv_materialized_test; --刪除物化視圖 --------------------------------------------------------------------- 物化視圖的刷新有二類，分別是：on commit ；on demand。刷新方法有三種分別是：快速（FAST），完全（COMPLETE），強制（FORCE）；ON COMMIT 與DEMAND 在應用中的問題 ON COMMIT 如果選擇on commit ，則在對主表應用上會造成速度，這是因為ORACLＥ在對主表操作提交后馬上會進行刷新物化視圖操作，這部分時間是也包括在提交時間中。a) refresh force on commit:中對刪，新增記錄，物理視圖都能真實反映主表的變化。同時這種情況下不用建物化視圖日志表。缺點是提交時間長。b) refresh fast on commit:中對新增或修改能真實反映主表的變化，但對刪除則不能反映，必須進行一次完全刷新。ON DEMAND DEMAND必須用DBMS_MVIEW.REFRESH存儲過程建立的JOB去定時刷新物化視圖。a) refresh fast on DEMAND:必須通過調用DBMS_MVIEW.REFRESH存儲過程來進行快速刷新反映主表新增情況；但當對主表中的數據刪除或修改時，快速刷新則會報錯，因此必須調DBMS_MVIEW.REFRESH的完全刷新才能反映?？梢酝ㄟ^建立JOB解決。表１：快速刷新declare v_mvname varchar2(50); begin v_mvname:='MOCHA_FE_DOC_CONTENT_MV'; dbms_mview.refresh(v_mvname,'f'); end; /表２：完全刷新declare v_mvname varchar2(50); begin v_mvname:='MOCHA_FE_DOC_CONTENT_MV'; dbms_mview.refresh(v_mvname,'C'); end; /注意：用FAST 刷新物化視圖，前提要新建物化視圖日志表。b) refresh force/complate on DEMAND:在這種方式下物化視圖也是無法自動刷新，必須通過JOB或手工。FAST、FORCE、COMPLETE區別 FAST：增量式刷新，使用此方法必須有前提，就是建立物化視圖日志表。FORCE:：如果可以以fast 方式刷新則用，否則完全刷新。COMPLETE：先將物化視圖表內容刪除，然后再刷新。此方式缺少就是在刷新時間內用法在頁面無法查到的所需要內容。 ---------------------------------------------------------------------------------- 官方文檔:https://docs.oracle.com/cd/E11882_01/server.112/e10706/repmview.htm#REPLN3351.1???概念 物化視圖?[1]??（Materialized View）在9i以前的版本叫做快照（SNAPSHOT)，從9i開始改名叫做物化視圖。它是用于預先計算并保存表連接或聚集等耗時較多的操作的結果，這樣，在執行查詢時，就可以避免進行這些耗時的操作，從而快速的得到結果。物化視圖有很多方面和索引很相似：使用物化視圖的目的是為了提高查詢性能；物化視圖對應用透明，增加和刪除物化視圖不會影響應用程序中SQL 語句的正確性和有效性；物化視圖需要占用存儲空間；當基表發生變化時，物化視圖也應當刷新。簡單說,物化視圖不僅存儲了sql的定義,還存儲了數據;它是遠程數據的的本地副本，或者用來生成基于數據表求和的匯總表。物化視圖存儲基于遠程表的數據，也可以稱為快照。物化視圖可以查詢表，視圖和其它的物化視圖。特點：(1) 物化視圖在某種意義上說就是一個物理表(而且不僅僅是一個物理表)，這通過其可以被user_tables查詢出來，而得到確認；(2) 物化視圖也是一種段(segment)，所以其有自己的物理存儲屬性；(3) 物化視圖會占用數據庫磁盤空間，這點從user_segment的查詢結果，可以得到佐證；創建語句：create materialized view mv_name asselect * from table_name因為物化視圖由于是物理真實存在的，故可以創建索引。字典:--物化視圖日志字典,可查看具體的日志表select* from dba_MVIEW_LOGS;?????--查看物化視圖,可以查到定義的各種條件以及更新時間,以及查詢語句等select* from DBA_MVIEWS;--物化視圖跟源對象的對應關系select * from all_mview_refresh_times aa whereaa.MASTER='EMP'and aa.NAME='MY_EMP_VIEW';1.1.1??語法create?materialized?view?view_namebuild?immediate|deferred refresh?[fast|complete|force] [on?[commit|demand]?| enable queryrewrite?|disable query rewrite? start?with?(start_time)?next?(next_time)]AS?查詢語句;默認: build?immediate,refresh force,on demand,disablequery rewrite含義:1創建時生成數據：分為兩種：build immediate?和?build deferred，build immediate是在創建物化視圖的時候就生成數據。build deferred則在創建時不生成數據，以后根據需要在生成數據。如果不指定，則默認為buildimmediate。2刷新模式：物化視圖有二種刷新模式：在創建時refresh mode是?ondemand?還是?on commit。on commit? 提交觸發，一旦基表有了commit，即事務提交，則立刻刷新;如果選擇on commit?，則在對主表應用上會造成速度，這是因為ORACLＥ在對主表操作提交后馬上會進行刷新物化視圖操作，這部分時間是也包括在提交時間中。a)?refresh?complete on commit:完全更新,不用建日志表,缺點是提交時間長。b)?refreshfast on commit:必須先建立日志表,增刪改都能同步 ,oracle11g經過測試得出;c) refresh force oncommit:先走fast,不行走completeon demand:手動刷新同步,調用過程DBMS_MVIEW.REFRESH,也可以建立job調用過程更新;相對于commit,只不過手動調用而已;a)?refresh completeon DEMAND:全量刷新b) refresh?fast on DEMAND: 同commit必須先建立日志表通過調用DBMS_MVIEW.REFRESH存儲過程來進行數據的刷新同步;c) refresh?force on DEMAND: 先走fast,不行走complete3細節如下:完全刷新（COMPLETE）：?會刪除表中所有的記錄（如果是單表刷新，可能會采用TRUNCATE的方式），然后根據物化視圖中查詢語句的定義重新生成物化視圖。快速刷新（FAST）：?采用增量刷新的機制，只將自上次刷新以后對基表進行的所有操作刷新到物化視圖中去。FAST必須創建基于主表的視圖日志。對于增量刷新選項，如果在子查詢中存在分析函數，則物化視圖不起作用。FORCE方式：這是默認的數據刷新方式。Oracle會自動判斷是否滿足快速刷新的條件，如果滿足則進行快速刷新，否則進行完全刷新。關于快速刷新fast：Oracle物化視圖的快速刷新機制是通過物化視圖日志完成的。Oracle通過一個物化視圖日志還可以支持多個物化視圖的快速刷新。快速更新必須要有物化視圖日志表,不論是commit還是demand;4查詢重寫（QueryRewrite）：包括?enablequery rewrite?和?disable query rewrite?兩種。分別指出創建的物化視圖是否支持查詢重寫。查詢重寫是指當對物化視圖的基表進行查詢時，oracle會自動判斷能否通過查詢物化視圖來得到結果，如果可以，則避免了聚集或連接操作，而直接從已經計算好的物化視圖中讀取數據。默認為disable queryrewrite。5fast刷新的限制：所有類型的快速刷新物化視圖都必須滿足的條件：1.物化視圖不能包含對不重復表達式的引用，如SYSDATE和ROWNUM；2.物化視圖不能包含對LONG和LONG?RAW數據類型的引用。只包含連接的物化視圖：1.必須滿足所有快速刷新物化視圖都滿足的條件；2.不能包括GROUP?BY語句或聚集操作；3.如果在WHERE語句中包含外連接，那么唯一約束必須存在于連接中內表的連接列上；4.如果不包含外連接，那么WHERE語句沒有限制，如果包含外連接，那么WHERE語句中只能使用AND連接，并且只能使用“＝”操作。5.FROM語句列表中所有表的ROWID必須出現在SELECT語句的列表中。1.2 ? 物化視圖日志 Following are the types of materializedview logs:Primary Key: The materialized view records changes to the master table or master materialized view based on the primary key of the affected rows. Row ID: The materialized view records changes to the master table or master materialized view based on the rowid of the affected rows. Object ID: The materialized view records changes to the master object table or master object materialized view based on the object identifier of the affected row objects. Combination: The materialized view records changes to the master table or master materialized view based any combination of the three options. It is possible to record changes based on the primary key, the?ROWID, and the object identifier of the affected rows. Such a materialized view log supports primary key,?ROWID, and object materialized views, which is helpful for environments that have all three types of materialized views based on a master. 翻譯：主鍵：物化視圖根據受影響行的主鍵記錄對主表或主物化視圖的更改。行ID：物化視圖根據受影響行的rowid記錄對主表或主物化視圖的更改。Object ID：物化視圖根據受影響行對象的對象標識符記錄對主對象表或主對象物化視圖的更改。組合：物化視圖記錄基于這三個選項的任意組合對主表或主物化視圖的更改?？梢愿鶕麈I、ROWID和受影響行的對象標識符記錄更改。這樣的物化視圖日志支持主鍵、ROWID和對象物化視圖，這對于基于主目錄擁有所有三種類型物化視圖的環境很有幫助。物化視圖日志根據不同物化視圖的快速刷新的需要，可以建立為ROWID或PRIMARY KEY類型的。還可以選擇是否包括SEQUENCE、INCLUDING NEW VALUES以及指定列的列表。底層應該還是用到了類似的行級觸發器;如:create materialized view log on emp--可以指定表空間tablespacetest_space -- 日志空間?with primary key;?--查看物化視圖的刷新情況select *from USER_MVIEW_LOGS;物化視圖日志的名稱為MLOG$_后面跟基表的名稱，如果表名的長度超過20位，則只取前20位，當截短后出現名稱重復時，Oracle會自動在物化視圖日志名稱后面加上數字作為序號。通過這個字典可以查找到具體的日志表;通過日志表就可以知道更新情況;--查看日志表select *from MLOG$_EMP? ;SNAPTIME$$：用于表示刷新時間。DMLTYPE$$：用于表示DML操作類型，I表示INSERT，D表示DELETE，U表示UPDATE。OLD_NEW$$：用于表示這個值是新值還是舊值。N（EW）表示新值，O（LD）表示舊值，U表示UPDATE操作。CHANGE_VECTOR$$：表示修改矢量，用來表示被修改的是哪個或哪幾個字段。當刷新完成后MLOG$_EMP相應的日志記錄,會被清空;在刷新(同步)物化視圖之前你可以做各種DML操作;在你提交之前就會記錄到日志表;------------------------------------------------------------------------------- 1. 用法物化視圖是包括一個查詢結果的數據庫對象，它是遠程數據的的本地副本，或者用來生成基于數據表求和的匯總表。物化視圖存儲基于遠程表的數據，也可以稱為快照。對于復制，物化視圖允許你在本地維護遠程數據的副本,這些副本是只讀的。如果你想修改本地副本，必須用高級復制的功能。當你想從一個表或視圖中抽取數據時，你可以用從物化視圖中抽取。對于數據倉庫，創建的物化視圖通常情況下是聚合視圖，單一表聚合視圖和連接視圖。 實現兩個數據庫之間的數據同步，可以存在時間差。1. 刷新的方式FastCompleteFource2. 刷新的方法DBMS_REFRESH.RefreshDBMS_MVIEW.Refresh2. 具體應用(1).在源數據庫建立mview log日志文件create materialized view log on w_1 ;----注：(TEST為表名或者視圖名，關于視圖上建立物化視圖，見基于視圖的物化視圖----創建物化視圖語句：(2).在統計數據建立materializad view 語法 Create materialized view MV_TEST----MVTEST為物化視圖名Build immediate----創建時生成數據對應的是build deferredRefresh fast----增量刷新On commit----在基表有更新時提交，這里該句對視圖無效With rowid----這里創建基于rowid的物化視圖，對應的是 primary keyAsSelect * from TEST;----生成物化視圖數據語句(3).調用時進行刷新dbms_refresh.refresh('W_1')--------------------------------------------------------------- oracle物化視圖 物化視圖是一種特殊的物理表，“物化”(Materialized)視圖是相對普通視圖而言的。普通視圖是虛擬表，應用的局限性大，任何對視圖的查詢，Oracle都實際上轉換為視圖SQL語句的查詢。這樣對整體查詢性能的提高，并沒有實質上的好處。創建物化視圖需要的權限：grant create materialized view to user_name; 創建語句：create materialized view mv_name [選項n] as select * from table_name;[選項1]：BUILD [immediate,deferred] 是否在創建視圖時生成數據，默認生成、deferred為不生成數據，需要的時候生成[選項2]：refresh [fast|complete|force|never] fast是增量刷新，或者叫快速刷新；complete為全表刷新；force為如果增量刷新可以使用則使用增量刷新，否則全表刷新；never則是不進行刷新（不使用）[選項3]：on [demand,commit] 即手工刷新和提交時刷新[選項4]：start with 通知數據庫完成從主表到本地表第一次復制的時間[選項5]：next 說明了刷新的時間間隔，下次刷新的時間=上次執行完成的時間+時間間隔例子1：create materialized view V_AB refresh force on commit as select * from a,b where a.id=b.id分析：創建一個物化視圖來存儲a,b兩個表的數據，force表示盡量使用增量刷新，但是這種寫法只會進行全表刷新。commit表示自動刷新，也就是說，當我們增刪改a,b表后進行commit操作后，我們的物化視圖也會同時進行數據的刷新。如果想要使用增量刷新來提高效率，請看下面的例子例子2：首先要建立與原表rowid相關的物化視圖：create materialized view log on A with rowid;create materialized view log on B with rowid;再創建真正的物化視圖create materialized view V_AB refresh fast on demand start with sysdate next sysdate+1/1440 as select a.rowid as arowid,b.rowid as browid, (其余字段) from a,b where a.id=b.id;這里使用demand代表手動刷新，start with代表開始復制的時間，next說明間隔一分鐘后刷新，也就是說，當我們增刪改a,b表后進行commit操作后，我們的物化視圖再經過1分鐘后會進行數據的刷新。查詢已經建立的物化視圖語句：SELECT * FROM user_mviews WHERE mview_name = '物化視圖名稱'; -------------------------------------------------------------------------

中間表的方案?

中間表的由來中間表是數據庫中專門存放中間計算結果的數據表。報表系統中的中間表是普遍存在的。那么，這些中間表是如何出現的？為什么中間表會越來越多？中間表會給項目組帶來什么樣的困擾，如何解決這些困擾？這里我們就嘗試探討一下這個問題。中間表出現的典型場景主要有三個：一步算不出來。數據庫中的原始數據表要經過復雜計算，才能在報表上展現出來。一個SQL很難實現這樣的復雜計算。要連續多個SQL實現，前面的生成中間表給后邊的SQL使用。實時計算等待時間過長。因為數據量大或者計算復雜，報表用戶等待時間太長。所以要每天晚上跑批量任務，把數據計算好之后存入中間表。報表用戶基于中間表查詢就會快很多。多樣性數據源參加計算。來自于文件、NOSQL、Webservice等的外部數據，需要與數據庫內數據進行混合計算時，傳統辦法只能導入數據庫形成中間表。中間表帶來的問題在一個運營商的報表系統中，我們發現了一個讓人吃驚的現象。在DB2數據倉庫中，有兩萬多個數據庫表！經過深入了解發現，真正的原始數據表只有幾百張，剩下的大量的數據庫表都是為查詢和報表服務的中間表。經過幾年乃至十幾年的運行，數據庫中的中間表越來越多，甚至出現這個項目中上萬個的情況。大量中間表帶來的直接困擾是數據庫存儲空間不夠用，面臨頻繁的擴容需求。中間表對應的存儲過程、觸發器等等需要占用數據庫的計算資源，也會造成數據庫的擴容壓力。那么，是不是可以清理掉一些不用的中間表？一般的結論都是：搞不動。數據庫中的中間表是不同程序員制作的，有的是綜合查詢系統使用，有的是報表系統使用。中間表之間還存在交叉引用，有些程序員看到有別人生成的中間表就直接使用了。有時候一些查詢報表已經廢棄不用了，但是對應的中間表沒人敢刪，因為不知道刪掉之后會影響其他什么查詢或者報表。很多情況下，項目組只好為了越來越多的中間表去擴容數據庫。但是數據庫的擴容成本太昂貴了：不管是換更強的服務器（縱向擴容），還是增加數據庫服務器的節點（橫向擴容），都不便宜。過于頻繁的擴容讓項目組非常頭疼。那么，能不能把中間表導出到文件中，從而減輕數據庫的壓力呢？這個辦法初看挺好，但是有個問題始終無法解決。例如：每天晚上把經營分析表數據生成好之后放到文件中，第二天上班的時候發現，業務人員還要對經營分析表按照各種條件過濾，或者按照各種維度分組。因為文件本身是沒有計算能力的，一旦把中間表從數據庫中導出成文件就很難進一步計算了。不得已，只能把中間表繼續留在數據庫中。解決問題的辦法采用潤乾集算器實現文件計算，就可以把中間表從庫中遷移到文件系統中了。采用集算器的前后對比圖如下：在集算器結構中，數據庫的大量中間表都移到了庫外，數據庫僅僅存儲少量原始數據表，壓力就小了很多。針對這些中間表實現的多個ETL存儲過程、觸發器、復雜SQL也都由集算器來實現，數據庫的計算壓力也變小了很多。雖然計算和存儲壓力由應用服務器來承擔，但是成本還是要比數據庫服務器低很多。項目組不用再每隔一段時間就申請數據庫服務器擴容了。同時，集算器可以讀取多樣性數據源，直接參與混合計算。無需再導入數據庫，成為中間表。集算器編程很容易移到庫外的數據文件不能再使用SQL計算了，換成集算器會不會增加編寫的難度呢？實際上，集算器編寫簡單計算腳本的時候和SQL差不多，復雜多步驟計算還要比SQL容易。例如：從上述例子來看，采用集算器實現數據文件庫外計算，學習成本很低，很容易掌握。新方案的價值新方案的價值還不僅僅是降低數據庫的壓力。對于報表應用而言，中間數據的存在是有價值的：有些中間表是報表業務決定的，有些是為了彌補現有技術的不足。也就是說，中間數據和報表模板一樣，都是報表系統的一部分。所以，集算器的方案并沒有讓中間數據消失，只是移到了庫外，保存在報表應用的文件目錄中，使得中間表在物理上也成為了報表應用系統的一部分。這樣既能發揮中間數據的價值，還可以讓中間數據和報表系統的其他部分一起管理。顯然，文件系統的樹形目錄結構比數據庫混在一起的幾萬個表要更容易維護。在實際項目中，可以給中間數據文件建立多層文件夾存儲。例如：第一層目錄是財務管理、人力資源、ERP等等。人力資源又有子目錄：工資管理，基本信息，黨員信息等等。目錄可以細化到某個報表，如果該報表發生了變化，只需要調整這個目錄中的報表模板或者數據文件即可。如果該報表廢棄不用，那么刪掉或者移走報表所在目錄，就可以快速的釋放硬盤空間。從計算速度來說，由于文件更底層，更接近于磁盤，IO性能要好于數據庫。所以集算器的方案可以為報表系統帶來更快的性能。報表數據來自于多樣性數據源時，還可以有更好的實時性，不像傳統手段時只能定期入庫。---------------------------------------------------------------------------------- 中間表起一種如關聯的作用。比如課件和課件包，他們之間的關系是，一個課件包有多個課件。如果建了一個中間表，專門用來關聯課件和課件包的。這樣，當要刪除一個課件的時候，只用先把這個中間表中關于這個這個課件的數據給刪除，然后再在課件的表中將該課件給刪除。這樣整個課件就刪除了。如果我是在課件包這端建立關聯關系，@OneToMany。這樣如果要用分頁獲取課件。（該課件包的課件）這個時候如果一個課件包有好多的課件，要進行分頁。@OneToMany就會不合適。如果在課件端建立關聯關系，@ManyToOne這樣分頁的問題是解決了，但是如果要刪除掉該課件，但是由于，課件與課件包關聯著，刪除課件會報錯。如果用課件與課件包中間表來解決此問題就會方便的多。刪除上面說了。分頁，只用將課件包的id得到就行。--------------------------------------------------------------------------------- 數據庫設計中，經常遇到一個決策：究竟是使用視圖，還是中間表？考慮庫存管理的一個場景：最普通的單據是入庫和出庫單，庫管員需要看到當前的庫存。對庫存的處理，我們有兩個方案：一是使用視圖，所有的入庫減去所有的出庫，就是當前庫存；另外就是使用中間表，建立一個庫存表，記錄當前的庫存。1、使用視圖的方案入庫時，系統記錄入庫單據；出庫時，系統查詢庫存視圖，判斷是否有充足的庫存可以出庫，然后記錄出庫單據；可見，系統只需要記錄入庫和出庫單據，庫存的計算是由DBMS在查詢視圖時進行的；2、使用庫存表的方案入庫時，系統記錄入庫單據，同時增加相應的庫存；出庫時，系統查詢庫存表，判斷是否有充足的庫存可以出庫，然后記錄出庫單據，減少相應的庫存；可見，系統除了記錄入庫和出庫單據外，還需要更新庫存表的當前庫存數量；3、方案的比較對系統本身的設計和編碼來說，視圖方案易于實現，測試方便；庫存表方案則稍微復雜。從這點上看，視圖方案可以在原型階段大展身手。用戶體驗到的性能方面，視圖方案的性能壓力在查詢庫存上，庫存表方案的性能壓力在業務處理上：視圖方案：由于每次查詢庫存，DBMS都需要掃描入庫和出庫單據，查詢時間長；還可能會對入庫和出庫單據加鎖，導致入庫和出庫處理延長，甚至失敗（尤其是查詢庫存視圖在一個事務中時）；庫存視圖如果和其它表或者視圖連接，構成復雜的SQL時，由于索引不能有效（或無法）使用，查詢速度會更慢；庫存表方案：庫存表上可以建索引，查詢速度比視圖會快很多；在入庫和出庫時，更新庫存表的SQL會對出入庫處理的速度有一些影響，但是由于更新只影響出入庫的SKU，與查詢庫存表并發時，加鎖時間非常短，影響會比較小。4、結論視圖方案適用情形：原型，數據量比較小；庫存表方案適用情形：數據量比較大，針對庫存的分析較多； -------------------------------------------------------------------------------------- 為了提高性能，對于中間表，的同步，采用初臺全量同步，每天，增量同步的方案。 我介紹一下我們增量方案吧！ 要增量，增量日志表是必需的，增量日志表的設計。KEY（原業務表關鍵字），CREATE_DATE(變更時間)，FLAG（數據修改與刪除標志），USE_FLAG（增量表是否被使用的記錄，（一個存儲過濾使用一位））每天增量同步時，做如下操作 --如果增量日志表，所有標志位都已經使用，把增量日志表移到增量日志備份表里 INSERT?LOG_MANUAL_INC_BAK? SELECT?* FROM?LOG_MANUAL_INC? WHERE?LEFT(USING_FLAG,4)='1111'DELETE?LOG_MANUAL_INC?WHERE?LEFT(USING_FLAG,4)='1111'--建臨時中間表，方便同步(字段內容與真實表一樣) CREATE?TABLE?#TG_ENTRY?([TE_ENTRY_ID]?[char]?(18)???NOT?NULL? ..)? GO---------------------將未整合記錄從中間表中刪除 --SUBSTRING(USING_FLAG,2,1)為這次整合使用的標記位DELETE?FROM?TG_ENTRY?WHERE?TG_ENTRY_ID?IN?(SELECT?TG_ENTRY_ID?FROM?LOG_MANUAL_INC?WHERE?SUBSTRING(USING_FLAG,2,1)<>1)。。下面就可以做同步數據了， 。。。同步數據是從原業務表里取，不過，數據范圍限定在，增量表里的沒有做增量操作(并且操作類型為新加與修改的)的數據也就同步多加一個WHERE條件， WHERE LOG_MANUAL_INC.ARJ_MARK='M' and SUBSTRING(USING_FLAG,2,1)<>1 取好的數據是放在新建的臨時中間表，#TG_ENTRY做好了同步操作，不要忘了更新增量表的標志。 ---------------------

?

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的oracle 物化视图、中间表的方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。