請教...資料庫程式設計實務 |
尚未結案
|
ccsam
一般會員 發表:6 回覆:8 積分:7 註冊:2003-07-11 發送簡訊給我 |
請問各位先進
當大家在設計大型資料庫程式時
遇到那種不得不存取大量資料的情況下
例如Select幾萬筆資料時
(假設這些資料是基本需求,不能再Filtering或下其他Where條件)
各位通常是怎麼做的?以下是我的想法
1.針對ADO元件作調整:對Dataset的Cachesize加大;某些情況CurserType設定為ctOpenForwardOnly
2.使用多執行緒來作Query的動作,然後顯示一個畫面如"資料正在存取中,請稍後!",應該是沒有辦法用Progressbar來表示存取的狀態,為了得到Progressbar.max屬性勢必要Select Count(*),這樣會拖垮系統吧!
不知道各位大大還有什麼特別的做法....與大家分享一下吧
|
Winifred
初階會員 發表:3 回覆:34 積分:47 註冊:2002-07-24 發送簡訊給我 |
|
ccsam
一般會員 發表:6 回覆:8 積分:7 註冊:2003-07-11 發送簡訊給我 |
引言: 這個問題之前我也有碰過類似的 不過以使用者的角度來看..應該沒有使用者會一次看幾萬筆的資料 我們通常一定會限制查詢的條件 會盡量避免 Select * from這樣的語句 如果只是純粹要讓DataSet Open的狀態 我都是用 Select Top 0 甚至是 Top 100...來查詢前幾筆的資料 只是您的"不能再Filtering或下其他Where條件"就有上萬筆的話 使用者一定要看的話.. 我也不知道還有什麼好方法... >>< face="Verdana, Arial, Helvetica"> 嗯.....會有這麼多資料量的原因是會用到歷史資料 來作展示(Grid),計算 也就是Select * from current_table union Select * from history_table 之後再作展示計算 我想Select top的方式可能比較適合分頁展示方法使用 用在Grid中可能不適合 使用者不一定要看資料,但是計算的結果卻是一定要出來的 table也建了index,可是我的select方式卻是full table scan的 select速度慢似乎無可避免,只是想能不能讓user有耐心的等下去 使用執行緒不要讓系統hang掉似乎是唯一較可行的方法? 所以希望能看到有創意的做法或想法,方法總是人想出來的,您說是吧 |
yachanga
資深會員 發表:24 回覆:335 積分:296 註冊:2003-09-27 發送簡訊給我 |
引言
--------------------------------------------------------------------- 嗯.....會有這麼多資料量的原因是會用到歷史資料
來作展示(Grid),計算
也就是Select * from current_table union Select * from history_table
之後再作展示計算
我想Select top的方式可能比較適合分頁展示方法使用
用在Grid中可能不適合
使用者不一定要看資料,但是計算的結果卻是一定要出來的
table也建了index,可是我的select方式卻是full table scan的
select速度慢似乎無可避免,只是想能不能讓user有耐心的等下去
使用執行緒不要讓系統hang掉似乎是唯一較可行的方法?
所以希望能看到有創意的做法或想法,方法總是人想出來的,您說是吧
--------------------------------------------------------------------- Hi.. 這個情況我有碰過, 通常遇到這個情況時我會和使用者溝通.
所謂事情沒有兩全其美的. 我建議如下:
(1) 找User溝通, 我想一般是需要"計算歷史資料",而不是看歷史Raw data,
所以資料時效性可以商量. 看資料重要程度, 一般一天更新一次,很重要的一小時甚至15分鐘更新一次. (2) 寫 Store procedure 將User 要的計算結果算出來寫到另一個Table,
通常需要跑個幾分鐘, 到時候User select 只要0.01秒, 嚇死他, 哈哈.. 這就是所謂Data mart, 或是Data Wharehouse觀念. 很多User想看的資料並不是
原始資料就可以呈現, 所以企業都會建構Data mart 來呈現重要的資料, 你覺得呢??
|
hahalin
版主 發表:295 回覆:1698 積分:823 註冊:2002-04-14 發送簡訊給我 |
|
yachanga
資深會員 發表:24 回覆:335 積分:296 註冊:2003-09-27 發送簡訊給我 |
Hi... hahalin 版主:
你愛說笑了...我試著解釋看看. 用比喻, data mart 就好是"資料超市". 資料庫的資料就好像是全部的飲料,
放在各地的工廠(database).
不見得大家都喜歡喝, 要喝又要到各地工廠找老半天.
所以就友人發明這個觀念, 將大家需要, 喜歡, 常喝的飲料放超市(data mart),
這樣大家喝飲料(Find Data) 就方便, 迅速了.
所以嚴格來說這個問題也不算是data mart, 沒那樣偉大.
當作做資料重整(Data Pre-summary)...就行 ~悠遊法國號~
|
personmen
一般會員 發表:7 回覆:12 積分:3 註冊:2003-11-14 發送簡訊給我 |
|
jojoboy
初階會員 發表:65 回覆:108 積分:34 註冊:2002-03-13 發送簡訊給我 |
這個問題其實挺現實的.....
一定是無法兩全其美的.....
小弟曾經遇到這個問題.....
通常都是讓USER痛一下....就給他Select下去....
呵~~~~雖然不道德...但....真的很難兼顧的....
不過,後來我改使用資料倉儲的方式去做.....
先把使用者的需求規劃出來,做成資料維度...
然後定時去跑..反正是歷史資料..讓主機晚上有空時,去做匯整加總的動作.
隔天....就OK了....嘿嘿...很炫哦
不過,在設計資料維度時,必須要溝通的很久..而且可能要重新切割資料表格
你可以參考參考
|
本站聲明 |
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。 2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。 3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇! |