Posted By: tjm (蔡哲民) on board 'program'
Title:      資料庫系統

    資料庫系統其實是教會與教會機構的關鍵程式之一，但是要寫一個合用
並且不受廠商控制的資料庫系統其實很不容易。

    單單使用Dbase III可以解決單一的資料庫問題，但是其複雜的語言並不
適合電腦不熟的人員使用，而且當擁有兩個以上的資料庫，而彼此關聯時，
就不是用DBASE III可以簡單解決了。而牽涉到網路的檔案鎖定問題，更不是
Dbase III可以直接解決，必須藉助簡單的程式才能解決。

    而對於一個教會或機構，若維持七八個資料庫，一定會有「資料重複」
以及「資料不一致」的問題。而辦個活動，一定要製造一個新的資料庫，
重新把那些無聊的住址、電話再打一次，好像是要練秘書的打字速度一樣。
呵呵呵！有時候是練到自己的打字速度。

    所以，資料庫的建立其實是一個教會或機構的關鍵技巧，做的好，
工作省力，資料一致。做的不好、就會讓打字的時間倍增，只剩下某些人可以
查詢特殊資料.....。反而成了絆腳石。

    而近代（想必過二、三十年也一樣）的資料庫主流，即是relation
database（關連式資料庫）。一般商用的資料庫系統都是這一個系統。

database（關連式資料庫）。一般商用的資料庫系統都是這一個系統。
其中心思想就是把資料當成幾個彼此有關係的表格。而建立這些資料庫，
就是要達到資料一致、不重複且可共用的目標，所以配合網路能力的
資料庫成為一個真正可用的資料庫系統的必須。

    怎樣讓資料庫成為可共用的呢？以下舉一個例子：

假設校園團契有七八個部門，有畢業生團契、團契部、青宣籌辦會....

而他們本來各有一個資料庫：

畢業生團契： 姓名、住址、電話、畢業學校、服事、教會
團契部：     姓名、住址、電話、畢業學校、年資、教會、帶領的團契
青宣籌辦會： 姓名、教會、住址、電話、分組、繳費情況


    而正好「蔡哲民」這人三者都參與，那就會有三份資料、三份住址.....
，他搬了家告訴他的輔導黃旭榮，黃哥跑去把團契部（假設他是團契部的人）
的資料叫秘書改了。而畢契仍然把契刊寄到舊地方，把奉獻代禱信寄到舊地方
，然後蔡哲民就沒有收到，就忘記要奉獻了。

    後來蔡哲民報名參加青宣，可憐處理的秘書苦哈哈的收到2000封報名單，
正好蔡哲民為了慎重起見，還把住址寫了個完完整整，害秘書一面罵一面輸入

正好蔡哲民為了慎重起見，還把住址寫了個完完整整，害秘書一面罵一面輸入
（因為蔡哲民的字差嘛！），一不小心把「建新路」打成「建興路」（他是用注
音的），一時蔡哲民就沒有收到赴會通知，氣都氣死了。

    後來校園團契要統計他底下到底有多少成大的人，哇！這下可操死秘書了！
不但不知道蔡哲民這傢伙出現在幾個地方，還有時寫「成大」、有時寫「交大」
、有時寫「成功大學」、有時寫「交通大學」......。只好回報！不可能！除非
用手算。可憐的總幹事說：「要用手算何必輸入電腦呢？」

    好啦！後來要開台北地區成大畢業生聯誼會，這回秘書厲害啦！懂得有人
成大，有人用成功大學，有人把成大寫在畢業學校的第一個、有人寫在第三個
、有人出現在資料庫A，有人在B......。

    沒關係，成大重要嘛！全部抓出來，重複寄邀請卡也沒關係。
不幸的是：蔡哲民又混了，這回他只寫了「北市」，而青宣資料庫又沒被想到
，好啦！這下他又沒被找到啦！結果校園團契就永遠失去這個人了，因為他又
搬家這回連住址都懶得給黃哥了。

    其實到最後，資料庫根本就剩下列印通訊錄的功能了，呵呵呵！那當然還是用
Dbase III就可以啦！

    怎麼辦呢？聽我下回分解！

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    
好！遇到上次那個問題後，南部的小鱉鱉，為校園團契設計一套relational
data 
base，透過網路的功能，達到資料共用的目標，也間接解決了資料不一致的
問題，小鱉鱉是高手喔！雖然大學死不學電腦，現在可是電腦高手呢！這樣的軟
體，也不過花了他三個月的時間就弄出來了，厲害吧！還不要錢喔！

偉大的新軟體架構大致如下：

    首先，各部門有一個共用的「人力資料庫系統」架構如下：

姓名、住址、電話、畢業學校、教會、教會服事、學歷、性別、配偶......

    然後把各部們的資料庫調整如下：

畢業生團契： 姓名、服事
團契部：     姓名、年資、帶領的團契
青宣籌辦會： 姓名、分組、繳費情況

   其他原來需要而現在沒有的資料則透過「姓名」到人力資料庫去找資料。



   這樣當「蔡哲民」的資料修正，而黃旭榮的秘書把團契部內的蔡哲民的資料
改過後，全校園團契都得到新資料了。

   而青宣的報名小組單單打上了「蔡哲民」三個字，就得到了所有的資料，
他們只要對照一下、填入分組、繳費資料就好了。太忙了就連對照也不用了。
而如果這時候蔡哲民改住址，又可以更正順便讓大家知道了。

    喔！為了要達成這個程式的最大功能，小鱉鱉還要大家遵守共同的規範，
例如「成大」、「成功大學」，就統一成「成功大學」，住台北的，就打「台北
市」 ，是「台北」不是「臺北」喔！

    好了，這下總幹事笑嘻嘻的，要拿台北的成大人？到人力資料庫找一下，
一個也不漏掉。每個部門接觸的新人，都乖乖的落入人力資料庫當中，格式還
統一。這下要錢、要人都方便了。

    要辦高雄地區交大團契校友會嗎？簡單，一下子就解決了。阿！大靈班
要找輔導嗎？喔！查一下就知道有誰可以用了。

    秘書也笑嘻嘻的，本來最恨的「住址」一欄，從此不用多打，哈哈哈！
還可以打電話多關心高中生喔！

    好景不常！可憐的小鱉鱉住在南部啦！而這程式是用clipper寫的，而
校園團契正好沒有人懂這東西（懂也不敢亂動！），今天有人發現住址欄位
太短啦！有人希望把造就記錄加進去啦！畢業生團契要加上分組資料啦！...
可憐的小鱉鱉，只為了三秒鐘的事情，得苦哈哈的坐半天車跑去台北......。

    小鱉鱉一方面認為自己倒楣，怎麼會認識黃旭榮呢？一方面又恨台北怎
麼會沒有人懂，幾次下來，他就把電話號碼換了，不讓大家知道.....。少了
小鱉鱉的修改軟體，不久資料庫就越來越不符合需要了，大家只好走回頭路
，又用Dbase III了。沒辦法嘛！分個組都不能。可憐當初決定要用小鱉鱉
程式的總幹事，只好苦哈哈的自己K軟體啦！一面傳道一面織帳棚，效法保羅
的精神。

    這回又失敗了，沒關係！我們下回再試一次。反正這些都是虛構的故事，
（人名雷同純屬巧合），只是要介紹大家怎麼用以及設計、選擇好資料庫軟體
罷了。

    其實為了改需求，被軟體公司套牢的人也不在少數。
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    這回好景不常，小鱉鱉參加弟兄小亮亮的婚禮時，居然又被總幹事抓到，這下糗
大了，住址電話又被問走了。還好在喜宴中，小鱉鱉遇到武林高手小煌煌，小煌煌聽
到小鱉鱉的遭遇，偷偷傳授小鱉鱉一招....。

    話說喜宴後三個月，小鱉鱉謝絕一切訪客與服事，努力修改程式，總幹事問起，
一律回答「程式要大修改」，絕不北上。

    三個月後，小鱉鱉的新作出爐，看起來跟前幾套一樣，用法也差不多，不過這回
小鱉鱉向總幹事借了一個校園團契最懂電腦的秘書，言明要借一個禮拜，好好教育。
這回大家都覺得奇怪，何必這麼麻煩呢？程式改一改還要三個月，還要學一個禮拜？
幹嘛嘛！不過在小鱉鱉的堅持之下，小紅紅被派出來學了。

    新程式除了執行檔、資料庫檔案、索引檔之外，還有幾個莫名其妙的檔案，另外
程式的進入速度慢了許多（不過反正大家也不覺得）。新程式一共有以下幾種檔案：

    readme 說明文件
    .exe   執行檔
    .dbf   資料庫檔案
    .ntx   索引檔

    .ntx   索引檔
    .def   不明物體一
    .dsp   不明物體二
    .prt   不明物體三
    .rel   不明物體四

    小紅紅不愧是高手，一眼就看出那四個不明物體才是重點所在，不過她還是按部
就班的「複習」一下新程式的功能（因為跟舊程式差不多）。這樣一天就過去了。

    第二天，小鱉鱉告訴小紅紅，要她學「修改」程式的運作，小紅紅聽見大吃一驚
，嚇呆了！忙說：「不不不！我不會寫程式。」，小鱉鱉氣定神閒的說：不是要妳寫
程式，是要妳「看圖說故事」.....。

    原來小鱉鱉把所有的資料庫與索引檔定義都寫在.def 檔案中、所有的螢幕顯示都
寫在 .dsp 中、所有的印表格式都寫在.prt 中、所有的資料庫的關聯關係都定義在.rel
檔
案中。而程式執行時會自動解讀這幾個檔案中的設定來繼續執行程式（類似 PE2 ）。
所以小紅紅只要稍稍修改那四個不明物體， 就能夠修改整個程式的執行結果，這就叫
以「時間換取空間」，喔！不！是以「時間換取可變性」。

    好啦！剩下的六天小紅紅一邊學習，一邊測試那四個不明檔案的功能與變化。 後
來就高高興興的回去校園團契了。



    喔！這回畢業生團契要加上分組資料嗎？您就看見小紅紅一邊吃午餐，一邊談笑
風生的把.def 和.dsp 改了一下，十分鐘之後一個嶄新的畫面就出現了。哦？大專靈
修班要增加興趣分組？那簡單，又是半小時就結束了。這回大家興趣來了，看到小紅
紅那麼厲害，就有人把以前住址空間太小的問題提出來了，看小紅紅怎麼辦。喔！她
這回用了兩小時才改完，不過修改只有十分鐘，資料重建費了一小時五十分鐘，沒辦
法，資料庫大嘛！

    這回大家都滿意了，小鱉鱉高高興興的回家研究新版程式，小紅紅幾乎處理掉所
有的問題，偶爾才非得要小鱉鱉上場不可，而且這回只要寄一塊磁片到台北就好，把
執行檔換掉就好啦！人也不用去。因為小紅紅瞭解每一個資料庫的細部內容，也自己
會設定，小鱉鱉只要改改程式就沒事了，不用上去處理，也不用教人家怎麼使用新程
式，反正程式的介面都一樣，校園團契各部門的應用程式都是這一套，總幹事還送每
個校園同工一套（不要錢嘛！）回家管自己的通訊錄，最後校園同工都會啦，就懶得
事事找秘書，反正那麼簡單，自己玩一玩就好，不會問一下小紅紅也就夠了，好一副
美滿的天倫樂圖。

    校園團契只有 30 台 PC， 蠻簡單的，用這一招就打發掉所有的問題了，不過如
果發展到更多人使用 PC 時，那就麻煩了，那就等下一集為大家介紹 client-server
架構。
﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍
    我已經寫好了 DOS 版的「開放性資料庫軟體」， 正好適合於一般教會機構使用
，我打算對教會機構當成 freeware 讓大家使用。

    這套 DB-COWORKER  系統是源於當兵時有朋友寫了一套不錯的單一資料庫軟體，
他把source code給我，初期我就直接修改他的source code。最後就遇到「改不完」
的問題。正好退伍兩年後我要結婚，我就把原來的程式全面改寫成「開放性資料庫系
統」，用來處理喜帖問題。結完婚後慢慢增強功能，加入關聯檔的處理能力，並在學
校（交大）的畢業生輔導組使用，有兩萬筆資料的實際處理經驗驗證其適用性。其他
小型的資料庫系統也有一些使用的實例。

    如果 ykl 有空，我會請他把程式放到本站的 FTP site，如果您是教會機構，就
請免費拿去使用，如果要玩玩，也不要客氣，拿去玩一玩。由於功能修改太快，有些
新功能我還來不及寫到readme中，請見諒，我後來會慢慢修改。

    此軟體有網路功能，可以處理多重資料庫，不過我現在只用過一個關聯檔，多個
關聯檔的情況沒有好好測試過。另外也有 window 版，不過實在太慢太醜了，我看不
拿出來也罷， 要等南部的小鱉鱉真的寫出開放的 foxpro 軟體， 我們才會真正推出
window 版。至於 VC++ 的 ODBC 版（含 client-server 架構），那就要更久了。

-----------------------------------------------------------------

==> 在 ykl (元柯) 的文章中提到:

----------------------------------------------------------------

==> 在 tjm (蔡哲民)  on board 'program' 的文章中提到：
 
    謝謝元柯，唉！我另外的一個困擾就是我的readme一直趕不上新功能。
而且系統複雜以後，就需要一點教學範例來教導使用者，但這不知道要拖多
久才能弄出來。

    昨天孝之說他要回去試，我看大概也會有不知如何處理之感受吧？
其實校園飛颺系統是不錯的教育系統，孝之可以把其中的定義檔一類的
全部copy過來套上DOS版的執行檔即可。

    readme部份，求神給我智慧，我再繼續努力。

-----------------------------------------------------------------
==> 在 shan (小雞) on board 'program' 的文章中提到：

如何發展校園的client-server確是大問題。需求分析，架構討論，人力安排，測試方式
等等，這正是明煌，哲民，孟僑和小雞10,11日開會的主題。


校園現在已開始出現這個問題了！經常兩三人同時列印複雜中文文件時，網路就明顯
變慢。網路瓶頸因素實在太多，咱們現在開始client-server架構，絕對不會太早。
我現在先設法解決CWin，中文字形，圖檔等所造成的網路壅塞，讓將來資料庫網路化
時能暢行無阻。


文字部有錢可以養全時間的專業資料庫人員，企劃案也大約成形，現在需要有人願意
全時間投入。

孝之

-----------------------------------------------------------------------

Posted By: tjm (蔡哲民) on board 'program'
Title:     Re: 資料庫系統（四）
Date:      Wed Feb  8 10:39:40 1995

==> 在 shan (小雞) 的文章中提到:

    嗯！不過您有沒有注意我舉例時都是舉要scan整個資料庫的例子？其實如果
不那麼做的話（善用INDEX檔），傳的資料根本不到列印的千分之一。所以圖檔，
列印檔、反而是現在的問題（這可以用內含中文字形的列表機或local列表機來解決）
，而client-server架構並不只有速度上有好處，在保護、recover上都有好處，
現在開始設計當然是必要的，但耗時甚長，如果現在設計，現在就要用的話，那真的
會逼死一堆英雄好漢了。

    所以設計當然是不嫌早，但是真正切入使用，是不是要那麼早？我是為孟僑擔心，
 只有他一個台北人，到時候他就會改程式改死，哈哈哈！我想一定要有開放系統的程
式開發完以後才能真正使用這種架構，而要開發完成，恐怕也得幾個月吧（我是說高手
來的話）？

    當然，還沒有開始討論，不能多說這樣的結論。不過開發freeware軟體真的是要
想多一點。


    嗯！如果這樣最好。但是全時間的資料庫人員也不可能寫Server，也得靠買的。
嘿嘿！當然像校園這樣的蒙上帝保守，買到便宜的Server，那是好的無比的，呵呵呵！
外面的server-client級的案子，大概都是以數十萬到百萬級的金額成交的，其實Server
太貴也是原因之一。

    server-client是一定要發展，但是一般的小機構，除非預估自己的資料量會大到
網路無法負載，又有多人會共用資料，才來考慮花大錢比較合適，不然解決一下圖形
和列印的問題會比較實際一點。這是我的看法。

    在實際的經驗中，用386-20 4M RAM當FILE SERVER，工作站用386級的機器跑，
在兩萬筆的資料下，三、四個人共用時，找一個人只要一秒以下，印表時還是印表機
的速度是瓶頸。當然，我是說索引後啦，硬找的話，大概要半小時才能找完整個資料
庫。

    一般的設計都不會去硬找的，所以雜誌上這樣說也沒有錯，我們的努力也是應該的。

--------------------------------------------------------------------------

Posted By: tjm (蔡哲民) on board 'program'
Title:     Re: 資料庫系統（四）
Date:      Wed Feb  8 10:57:01 1995

==> 在 shan (小雞) 的文章中提到:

    我舉的例子雖然是校園團契，但是目的卻是所有的教會機構，所以結論也是針對
所有的教會機構。

    至於校園團契，說真的，舉例的情況不是不可能發生。所以當然要發展，
而且要第一個發展。有個先鋒，以後的人要做就簡單了。現在有那個機構有
十萬筆以上資料的實力可以讓client-server架構發揮其實力呢？

    哈哈哈！孝之，您還要多擔待喔！