VFP 愛用者社區

[john]

to 朱Mr.

我的傳票檔大約5mega...請問你有幾台 users to access the data?

and how long for you to reindex and unfragment the files like that?

[朱育興]

TO john:

你是指我嗎？

有關幾臺存取資料的問題，我想跟行業有關，我們的使用者習慣傳票檔是由一到三人維護(基於權責問題)，所以沒機會測試同時由非常多人存取；不過我想這跟規劃有關，基本是建議客戶使用終端機模式，若是採用這種模式的話，二三十人應該還不成問題。

我找了一個與你大小相近的傳票檔(約 8 MB) 做 reindex：
WIN2000,256 MB RAM,P4 2.26 GHz,用網路芳鄰執行要 4 秒
WIN2003 Sever,512 MB RAM,P3 1133MHz,用終端機模式執行要 2 秒

unfragment 這個意思不了解無法回答

[syntech]

這兩種方式的授權費用不一樣,終端機模式通常需要另外授權,費用不低,
所以一般應該都是網路磁碟機(網路芳鄰)方式執行

兩種執行方式也不一樣,
網路磁碟機方式是以工作站的機器,系統資源執行程式,資料是透過網路送到工作站,因為這點,所以才容易發生索引檔或資料檔損壞.網路傳輸時發生異常,才會導致索引檔或資料檔損壞.
終端機模式程式是以server的機器,系統資源執行程式,再把"執行畫面"送到工作站,因為資料並未離開server,基本上可視為"單機"情況,而在單機情況下,DBF是不容易發生索引檔或資料檔損壞,

效能上的差異也是如此,網路磁碟機執行時,透過網路傳遞資料,由工作站進行重組,
會受網路傳輸速度及工作站本身效能的影響,本例中,是server執行較快.

因為需要另外授權的關係,一般規劃都以網路磁碟機執行為主,把終端機模式當成次要,或是廉價web應用程式,例如鉅盛的web方案其實就是利用終端機模式把1 tier程式變成n tier程式來賣

intranet的終端機模式執行效率與網路傳輸速度有關,10 m 的環境就嚇嚇叫,只要server高級一點,就能供不少工作站使用,但是internet的應用,受限於server上傳速度,兩邊都使用雙向512,畫面還是必須調整至16色或256色,而且工作站還僅能支持不足10台使用,一般工作操作還可以,但是切勿執行印表功能,因為印表時是以metafile資料送出,大的令人無法想像,等待時間十分驚人.

unfragment,是指 pack 吧!

[朱育興]

WIN2000 以上不需額外付費，98 的才要。(我記得是這樣的)

我們公司連主機 10 臺，印象中主機登錄後，其他 9 臺都用終端機模式使用，沒有額外付費的問題。不過這已是有段時間之前的事了(足夠讓我忘掉是怎麼回事了)。

[elleryq]

我記得是要錢啦~~
不過是以模式來分,有兩種模式:
管理者模式不要錢,但僅限兩個 Administrator 連進去
另外一種模式我忘記名字了,這個就要錢,連接限制就看你買的授權數目;而且可以用非 Administrator 身分的人登入.

[an1060]

目前台灣第二大套裝軟體是華翰電腦,其開發工具是VFP,工程師都是用大陸工程師
資料常出問題的原因是來自作業系統,其次是數據有問題而不是亂碼?
各位知道為何不是亂碼?因為他程式內部對資料寫入時善用BEGIN TRANSACTION,所以較少有亂碼問題。但速度慢的無法領叫,
因為他沒有善用索引檔之功能。

[syntech]

[an1060]

我所提的『數據問題』是指上述公司之套裝軟體,偶有客戶反應資料不正常,
例如:庫存數量應為20,卻出現24...等,若說是軟體問題,偏只有幾家會,不是每一
個USER都會.（不太像是部分TABLE未更新之問題）但我確定MS-SQL的儲存時
之觸發程式，會造成此現象，所以我無論MS-SQL或VFP之資料庫，打死我都不用觸發式程式，不談太多，否則會被那家公司告我誹謗.

BEGIN TRANSACTION,是在END TRANSACTION時才將BUFFER之資料一次寫入,如果此時作業系統或電腦硬體發生問題,當然是會造成FAT表與實際資料間有誤
差,但即使自己將DATA逐一寫入時,若發生系統及硬體問題時不也一樣會出現問題.
其最大好處是，在未下達END TRANSACTION時，發生系統或硬體，或諸多外力
不可抗拒之因素而造成資料寫入中斷時，不會發生部份TABLE已寫入，而部份未寫入之問題，當然若是VFP本身之交易理程序有問題，那就另當別論,不過這問題我尚未遇到過,可能是我開發的系統都不大吧!

用慣自己的習慣指令,而摒棄新功能不用是大部份程式設計師常遇到的現象,因為
不太信任看不見其內部的處理方式,

就VFP6而言,TRANSFORM()很好用,但有問題,所以我已摒棄不用,
STRZERO()在CLIPPER有,VFP就是沒有,所以只好自己寫,雖然可用
STRTRAN(XXX," ", "0")，但看上去總感覺複雜，因為我喜歡程式碼
越短越好,看上去能一目了然更好.

善用索引檔之功能，可有效增加效能，但因SQL語法較簡單，所以很多人
都儘可能用SQL語法，而不自己用非SQL語法來取資料，所以會造成速度變慢。
COMBOBOX及LISTBOX很好用，但它們都會將TABLE檔中之資料複製一份到
該物件之BUFFER中，而造成速度變慢，忘了說，我說的善用索引檔之原由，是
在畫面中提供資料內容供使用者參考選擇時.

[john59]

善用索引檔之功能，可有效增加效能，但因SQL語法較簡單，所以很多人
都儘可能用SQL語法，而不自己用非SQL語法來取資料，所以會造成速度變慢。
COMBOBOX及LISTBOX很好用，但它們都會將TABLE檔中之資料複製一份到
該物件之BUFFER中，而造成速度變慢，忘了說，我說的善用索引檔之原由，是
在畫面中提供資料內容供使用者參考選擇時.
===========================================
關於這點我深表同感,剛轉到vfp6時以為用sql
才跟得上潮流,沒想到軟體上線多機運作時速度慢到無法忍受而且還是非常簡短的select而已,因此不得不回歸index seek 再作後續處理,處理資料
速度就如同打通任督二脈般,別的工具我不清楚
但在vfp內如要高效率運作盡量別採用sql語法
vfp index 效率實在很高,這是小弟的淺見.

[syntech]

[john59]

基本上,SQL 命令是會使用RUSHMORE技術存取資料的,
若是條件符合INDEX SEEK ,
會自動使用INDEX SEEK,

那麼為什麼會覺得SQL 較慢?
沒有理由,VFP會不知道SQL命令是最常用的,最需要調整執行效率的?
=============================================
小弟才疏真的不大清楚sql內部最佳化運作機制為何
有參考過類似討論,譬如例子所述用like 比用 =
要快許多但問題是有許多情況都必須要用=
因此sql要scan整個資料庫因此速度當然慢很多,
如以下例子請教兄台如此敘述sql到底有沒有用到
index呢?,model已有index檔cdx型態

select * from md where model=mod into tabl c:\mdtemp

[syntech]

為此作一個實驗:
實驗環境: VFP 6.0 SP5 中文版(所以以下訊息是中文的)

以下操作在 VFP 命令視窗(command windows)中操作:
1.建立兩個DBF TABLE
　　IST 包含 ITM_NO (C,18 ),.......
　　索引檔(CDX)
　　IST_A ITM_NO+XXXXXX(某欄位)

　　IID 包含 ITM_NO (C,18 ),.......
　　索引檔(CDX)
　　IID_A ITM_NO+XXXXXX(某欄位)

2. SET OPTIMIZE ON && 設定為最佳化
3. SYS(3054, 11) && 顯示rushmore 最佳化層級
4. select * from ist where itm_no='xxxxx' && 執行sql 命令觀察
5. 此時會顯示:
　　"Rushmore 最佳化層級 ist:無" && 不能最佳化
6. select * from ist join iid on ist.itm_no=iid.itm_no where ist.itm_no='xxxxx' AND iid.itm_no='xxxxx' && 執行雙table join
7. 此時會顯示:
　　"Rushmore 最佳化層級 ist:無" && 不能最佳化
　　"Rushmore 最佳化層級 iid:無" && 不能最佳化
　　"Joining iid and ist 使用臨時索引" && Rushmore介入,建立臨時索引
8. 增建兩個索引
　　IST_B ITM_NO
　　IID_B ITM_NO
9. 重新執行4
10. 此時會顯示:
　　"Using 索引 tag Ist_b 對於rushmore最佳化 ist"
　　"Rushmore最佳化層級 ist :partial"
11. 重新執行6
12. 此時會顯示:
　　"Using 索引 tag Ist_b 對於rushmore最佳化 ist"
　　"Rushmore最佳化層級 ist :partial"
　　"Using 索引 tag Iid_b 對於rushmore最佳化 iid"
　　"Rushmore最佳化層級 iid :partial"
　　"Joining iid and ist using 索引 tag Ist_e"

需要再說些什麼嗎?

[john59]

"Joining iid and ist 使用臨時索引" && Rushmore介入,建立臨時索引
8. 增建兩個索引
　　IST_B ITM_NO
　　IID_B ITM_NO
9. 重新執行4
10. 此時會顯示:
　　"Using 索引 tag Ist_b 對於rushmore最佳化 ist"
　　"Rushmore最佳化層級 ist :partial"
==============================================
那再請教syntech 兄

是不是每次執行是否都要增建兩個索引呢?
　　IST_B ITM_NO
　　IID_B ITM_NO
如果是這樣,姑且不管其是否最佳化
1.dbf的資料如果不多那也無所謂,如果dbf的資料筆數
有50萬甚至上百萬筆那效率上是否會打折扣呢?
2.我個人覺得sql又臭又長的語法,還不如用vfp的
xbase語法用index seek再作後續處理,來的直接簡潔
效率高,當然這是我個人的經驗啦,用其它工具的話
那也就只能遷就sql了,感謝您熱心提出資料,有空我會拿來試試看到底哪個快.

[syntech]

應該這麼說,
既然是INDEX SEEK ,
當然應該以'完全符合索引欄位'為準,
看來SQL 命令會有這種取向,
所以當while條件式與index 欄位不符合時,
就無法利用rushmore的優點,
不是scan table 就是變成必須建立臨時index

用xbase index seek 的語法,不同處在於
即使用 IST_A ITM_NO+XXXXXX(某欄位) 這樣的索引,
下 SEEK 'xxxxx' 或是 seek('xxxxx')
一樣能用到index seek的優點,
不需要非得完全match索引欄位不可.
只能說vfp還沒聰明到這裡吧.
m$ sql 這裡好一點,一樣是index seek.

如果沒有適當的index,vfp會建立臨時index,
就這點而言,建立join 時的hash table,這樣做的確比沒有index時要快,

不過由help 得知,
單一table 應該用 for,
多table 應該用 select sql ,
才能獲得rushmore的優點,
在實驗中可以發現,
單一table作select 時,不會自己建立臨時索引,還是作scan table,
只有在多table select 時,會自己建立臨時索引,
不曉得是不是在說明這件事,

不是不能用牛刀殺雞,也不是不能用殺雞刀殺牛,
xbase及sql 命令都有其好用及不好用之處,
而是必須作到'不滯於物',
獨孤求敗有云:
「紫薇軟劍，三十歲前所用，誤傷義不祥，乃棄之深谷。」 <--- 只會用兵器取勝是沒用的
「重劍無鋒，大巧不工。四十歲前恃之橫行天下。」 <---- 回歸到兵器的本質才是正途
「四十歲後，不滯於物，草木竹石均可為劍。自此精修，漸進於無劍勝有劍之境。 」 <----- 不管是什麼兵器,但是傷人的方式並沒有不同,也就不需要管拿什麼兵器
也可以供大家參考.

[marvin]