 |
VFP 愛用者社區
本討論區為 Visual Foxpro 愛用者經驗交流的地方, 請多多利用"搜尋"的功能, 先查看看有無前例可循, 如果還有不懂的再發問. 部份主題有附加檔案, 須先註冊成為社區居民才可以下載.
|
| 上一篇主題 :: 下一篇主題 |
| 發表人 |
內容 |
chgc
註冊時間: 2009-04-27
文章: 13
第 1 樓
|
 發表於: 星期三 十一月 17, 2010 3:41 pm 文章主題: 老問題在確認一次，vfp dbc在區域網路下的執行速度 |
 |
|
我知道這是老問題了，我也讀了許多這方面的文章或討論
只是想知道是不是當foxpro的datatable的檔案大小到一定大小的時候，在區域網路的環境下，就會出現因為讀取資料需要搬移db而造成等待時間很久的情形發生
如果是的話，在網路環境下 300MB的datatable算很大嗎? 還是說有其他比較有效的改善方案呢?
請指教，謝謝 |
|
| 回頂端 |
|
 |
syntech
註冊時間: 2003-05-16
文章: 4212
來自: Taipei,Taiwan
第 2 樓
|
| 發表於: 星期三 十一月 17, 2010 5:34 pm 文章主題: |
|
|
做的正確就速度就正常,做的不正確,速度就更慢,
速度正常不表示速度快.
XD
_________________
如果公司有下列困擾:
1. 找不到便宜,快速,簡易的 生產排程軟體
2. 不知道如何快速排定 採購計劃
3. 成本抓不準,自己算比軟體算有用
4. 想學習系統規劃,想找系統架構的顧問
請聯絡我們,也許我們幫得上忙 |
|
| 回頂端 |
|
|
LiuRambo
註冊時間: 2007-11-27
文章: 481
第 3 樓
|
| 發表於: 星期三 十一月 17, 2010 9:38 pm 文章主題: |
|
|
300MB是單一檔還是全部DBF 這差很大
光是單純COPY檔案就得花上不少時間 更別提是在網路上跑迴圈處理資料
300MB是該換SQL上場了吧 |
|
| 回頂端 |
|
|
chgc
註冊時間: 2009-04-27
文章: 13
第 4 樓
|
| 發表於: 星期四 十一月 18, 2010 12:00 am 文章主題: |
|
|
300MB是單一檔案，
就像syntech大說得，光透過網路搬300MB的檔案也是需要一些時間，所以感覺看起來是正常的，只是想說能不能有偷雞的方式加快一下速度
SQL的部份可能就∼∼有些難度，畢竟sql server想要更新資料表的格式比較麻煩，產品化的程式又更加複雜了。 |
|
| 回頂端 |
|
|
syntech
註冊時間: 2003-05-16
文章: 4212
來自: Taipei,Taiwan
第 5 樓
|
| 發表於: 星期四 十一月 18, 2010 6:35 am 文章主題: |
|
|
檔案越大,索引的處理越重要.
不想換SQL就是得注意盡量保持搜尋最佳化的情況.
否則面臨必須直接對300M檔案逐筆處理,速度絕對完蛋.
這就是所謂"作的正確,速度就正常"
HELP中的RUSHMORE 章節研究研究吧.
_________________
如果公司有下列困擾:
1. 找不到便宜,快速,簡易的 生產排程軟體
2. 不知道如何快速排定 採購計劃
3. 成本抓不準,自己算比軟體算有用
4. 想學習系統規劃,想找系統架構的顧問
請聯絡我們,也許我們幫得上忙 |
|
| 回頂端 |
|
|
chgc
註冊時間: 2009-04-27
文章: 13
第 6 樓
|
| 發表於: 星期四 十一月 18, 2010 3:22 pm 文章主題: |
|
|
| 感謝各位的指點....謝謝 |
|
| 回頂端 |
|
|
syntech
註冊時間: 2003-05-16
文章: 4212
來自: Taipei,Taiwan
第 7 樓
|
| 發表於: 星期四 十一月 18, 2010 4:11 pm 文章主題: |
|
|
不然你就得找 CLIPPER/DBASE 時代的老書,
裡面會有比較多傳統xBASE語法的做法.
有VFP 以來,這類書就很少.
3.0時代還有一些從FPW轉過來的舊語法老書,
我還有收集到幾本,
之後就沒有了,
所以很多新用戶的根基都不扎實,
其實和許多老前輩相比,
我也算不扎實的那一群,
因為我小時候CLIPPER用的不深.
_________________
如果公司有下列困擾:
1. 找不到便宜,快速,簡易的 生產排程軟體
2. 不知道如何快速排定 採購計劃
3. 成本抓不準,自己算比軟體算有用
4. 想學習系統規劃,想找系統架構的顧問
請聯絡我們,也許我們幫得上忙 |
|
| 回頂端 |
|
|
aizz
註冊時間: 2007-01-29
文章: 171
第 8 樓
|
| 發表於: 星期四 十一月 18, 2010 6:14 pm 文章主題: |
|
|
| syntech 寫到: | 不然你就得找 CLIPPER/DBASE 時代的老書,
裡面會有比較多傳統xBASE語法的做法.
有VFP 以來,這類書就很少.
3.0時代還有一些從FPW轉過來的舊語法老書,
我還有收集到幾本,
之後就沒有了,
所以很多新用戶的根基都不扎實,
其實和許多老前輩相比,
我也算不扎實的那一群,
因為我小時候CLIPPER用的不深. |
我開始用 CLIPPER 的時候, 已經40歲了......
可, 我也用得不深
 |
|
| 回頂端 |
|
|
green
註冊時間: 2003-09-19
文章: 136
第 9 樓
|
| 發表於: 星期四 十一月 18, 2010 10:04 pm 文章主題: |
|
|
| 這裏有我以前的老闆嗎?感覺大家都很資深吶 |
|
| 回頂端 |
|
|
jeff25
註冊時間: 2004-10-22
文章: 76
來自: taiwan
第 10 樓
|
| 發表於: 星期五 十一月 19, 2010 8:56 am 文章主題: |
|
|
>>在網路環境下 300MB的datatable算很大嗎?
不會呀, 公司許多的單一dbf/cdx 也有超過 500 mb,且大於 500mb 的 dbf 也有20幾個, 因為這些都是存 10幾年
的異動檔,目前新增出貨單還是寫入這些檔,12個人同時打出貨單,速度也 ok,比較擔心的是vfp 單一 dbf 最大只支援到 2GB, 到時可能要拆出一個歷史檔,所以檔案大小不是一個影響速度的關鍵(pack/reindex 除外), 應該要善用 vfp rushmore 的功能
_________________
jeff |
|
| 回頂端 |
|
|
chgc
註冊時間: 2009-04-27
文章: 13
第 11 樓
|
| 發表於: 星期五 十一月 19, 2010 9:38 am 文章主題: |
|
|
jeff25:
新增修改時速度並不慢，感覺速度正常，只是在查詢時候就明顯感覺到網卡很忙碌。所以才會懷疑是不是vfp在查詢時的動作是搬移所查詢的資料表格到本機。 |
|
| 回頂端 |
|
|
syntech
註冊時間: 2003-05-16
文章: 4212
來自: Taipei,Taiwan
第 12 樓
|
| 發表於: 星期五 十一月 19, 2010 11:22 am 文章主題: |
|
|
不用懷疑.本來就是這樣.
不然要發展 sql server 這類的db server 做甚麼?
_________________
如果公司有下列困擾:
1. 找不到便宜,快速,簡易的 生產排程軟體
2. 不知道如何快速排定 採購計劃
3. 成本抓不準,自己算比軟體算有用
4. 想學習系統規劃,想找系統架構的顧問
請聯絡我們,也許我們幫得上忙 |
|
| 回頂端 |
|
|
jeff25
註冊時間: 2004-10-22
文章: 76
來自: taiwan
第 13 樓
|
| 發表於: 星期五 十一月 19, 2010 6:22 pm 文章主題: |
|
|
| chgc 寫到: | jeff25:
新增修改時速度並不慢，感覺速度正常，只是在查詢時候就明顯感覺到網卡很忙碌。所以才會懷疑是不是vfp在查詢時的動作是搬移所查詢的資料表格到本機。 |
的確查詢時會將資料由主機傳回工作站做處理或判斷,如果查詢的欄位條件沒在 index key 會將整個 dbf 傳回,檔案太大速度當然就慢了, 如果有 match vfp
的rushmore 只會將符合 index key 值的資料傳回,這樣就跟檔案大小無關, 因為傳回的資料就是你要的資料,例如你要的資料有 10mb, 就傳回 10 mb, 管它dbf檔是 300mb 或 30 mb (這只是簡化說明,實際資料傳回的方式是沒這麼單純的)公司在製作銷貨統計表時 採 rushmore 方式,現在跟 5 年前速度是差不多的,查詢1個月3000X25=約7萬筆資料也不超過15秒,所以善用 index 做好 3rd Normal Form 與好的 資料庫結構設計 通常是效率的主要關鍵.
_________________
jeff |
|
| 回頂端 |
|
|
xjliaos
註冊時間: 2007-11-20
文章: 87
來自: guan dong
第 14 樓
|
| 發表於: 星期六 十一月 20, 2010 3:19 pm 文章主題: |
|
|
| 300M的文件是有點大,但是你用SEEK來找資料,速度也是很快的,這個跟你的程式怎么寫很大關系. |
|
| 回頂端 |
|
|
foxy
註冊時間: 2007-08-16
文章: 231
來自: 泰國
第 15 樓
|
| 發表於: 星期日 十一月 21, 2010 3:37 pm 文章主題: |
|
|
| jeff25 寫到: | | chgc 寫到: | jeff25:
新增修改時速度並不慢，感覺速度正常，只是在查詢時候就明顯感覺到網卡很忙碌。所以才會懷疑是不是vfp在查詢時的動作是搬移所查詢的資料表格到本機。 |
的確查詢時會將資料由主機傳回工作站做處理或判斷,如果查詢的欄位條件沒在 index key 會將整個 dbf 傳回,檔案太大速度當然就慢了, 如果有 match vfp
的rushmore 只會將符合 index key 值的資料傳回,這樣就跟檔案大小無關, 因為傳回的資料就是你要的資料,例如你要的資料有 10mb, 就傳回 10 mb, 管它dbf檔是 300mb 或 30 mb (這只是簡化說明,實際資料傳回的方式是沒這麼單純的)公司在製作銷貨統計表時 採 rushmore 方式,現在跟 5 年前速度是差不多的,查詢1個月3000X25=約7萬筆資料也不超過15秒,所以善用 index 做好 3rd Normal Form 與好的 資料庫結構設計 通常是效率的主要關鍵. |
如果有 match vfp
的rushmore 只會將符合 index key 值的資料傳回,這樣就跟檔案大小無關, 因為傳回的資料就是你要的資料,例如你要的資料有 10mb, 就傳回 10 mb, 管它dbf檔是 300mb 或 30 mb
真是這樣嗎?我一直以為只要使用某個DBF, 它所有資料都要下載到工作台.
_________________
進銷存+生產製造+會計+員工薪資+CRM+POS零售+餐廳手機app+電商手機app+電商網站,物流系統. 正/簡體中文,英,日,泰,緬甸文. MS SQL Server + 前台 VFP + PHP 網站 + Flutter 手機 App, 都共享 MS SQL Server的資料. www.foxacc.com LINE: mike-lm |
|
| 回頂端 |
|
|
|
|
您 無法 在這個版面發表文章
您 無法 在這個版面回覆文章
您 無法 在這個版面編輯文章
您 無法 在這個版面刪除文章
您 無法 在這個版面進行投票
您 無法 在這個版面附加檔案
您 無法 在這個版面下載檔案
|
|
常見問題
搜尋
會員列表
會員群組
會員註冊
個人資料
登入檢查您的私人訊息
登入
