tag:blogger.com,1999:blog-4004426250543371370.post301007797378545417..comments2009-05-15T11:46:46.091+08:00戰地記者http://www.blogger.com/profile/13001359733580300024noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-4004426250543371370.post-13163370368604147792009-04-12T20:39:00.000+08:002009-04-12T20:39:00.000+08:00不知道是怎樣大有為的組織機構....才可以留住像您這樣大有為的青年?<BR/><BR/>相信會讓這樣有清楚邏輯 的您會依然默默的守著冰冷螢幕前 耐心的解決暴力程式<BR/>這樣的組織或是工作環境<BR/>一定有特別的溫度...<BR/><BR/>複雜化問題 複雜化程序...<BR/>不比這樣找到臭蟲 簡化繁複<BR/>優雅<BR/><BR/>看到您解決這樣的暴力程式...<BR/>就知道您的優雅跟品味...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4004426250543371370.post-37442969348617296632009-04-12T20:16:00.000+08:002009-04-12T20:16:00.000+08:00F.Y.I <BR/><BR/>如下圖 Q_INV_TRN_, Q_1 這兩個 SQL 的內容完全一樣,一開始 Turnning 時以為是 2N 的問題類型,後來仔細看了Layout才發現紅色的Loop包在藍色的Loop裡面<BR/>這樣一來,問題的複雜度是 N 平方<BR/> <BR/>這隻程式是Turnning的典型,剛開發完成時感覺不出來,資料量一大就非常慢,以"異動日報表"的需求而言,使用者假設選看一天的明細<BR/><BR/>2000年平均每日約 3000筆Transactions<BR/>3000 X 3000 = 9百萬筆的 I/O 次數<BR/><BR/>2009年平均每日約 12000 ~ 15000 的異動筆數<BR/>12000 X 12000 = 144000000 已經到達 1億4千萬次..<BR/>如果日期範圍是10天/20天,那簡直是天文數字了<BR/><BR/>所以這隻報表會 Running 好幾個小時<BR/>建議只保留紅色框的那個 Query,還是可以達到 Master(SUM) - Detail 的Layout<BR/>原本這樣的方式,等於是暴力的使用兩次相同的 Query,一次只取 Master Summary,一次只取Detail,浪費了太多的 IO<BR/>如果只用一個 Query,保守的估計 5分鐘內會完成戰地記者http://www.blogger.com/profile/13001359733580300024noreply@blogger.com