由 simpleflow » 2009-10-17 22:00
一、前言
許多初學Lotus Notes（LotusNotes以下簡稱Notes）的朋友常常會因爲Notes學習範圍太廣、教育訓練課程太貴、中文資料太少⋯等等因素，而不知該從何開始入門學習。不過因爲這些因素而放棄的話，其實是非常之可惜的，畢竟Notes的功能及其整合性在羣組軟件領域中，仍然是領先其它羣組軟件的佼佼者。
Louis爲了讓許多初學Notes的朋友可以快速上手，所以決定着手撰寫此係列的文章，希望以最淺顯易懂的白話文來爲初學者建立Notes程序設計最基本的觀念（但會不會中斷不敢保證:p）。不過既然是「隨筆」，所以一些順序的編排就不會那麼的有系統。另外，在章文中雖然偶爾會提到一些技術觀念，但並不屬於高深的技術文件，純粹只是觀念養成的文章。若您想進一步瞭解文中提及的觀念時，Louis「強烈」建議直接參考Notes程序設計說明資料庫。當然，本系列文章中若有訛誤還請各位前輩高手多多指教。
二、Notes學習方向
Notes的學習方向主要分爲程序設計與系統管理兩部份，一般通稱爲Notes AD（ApplicationDevelopment）與SA（SystemAdministration），而這也是IBM官方的說法。不過，有時候AD也有人稱爲AP，而SA則常會與IT界常用的系統分析（SystemAnalysis）搞混，所以在與其它朋友交流時可千萬不要雞同鴨講。
但不論是NotesAD還是SA的知識，這兩者並無明確界線，而且兩者其實是相輔相成的。以ACL的設定來講，就無法明確歸納至AD或SA任一範疇，因爲不管是在開發應用程序（應用程序以下簡稱AP）或是管理Domino系統，ACL的設定都是必須的常識。另外，在開發WebAP時，爲了讓瀏覽器使用者可以正常瀏覽存取Web AP的內容與資料，也須要先在服務器上做一些設定，而這也是開發人員所須要瞭解的。
所以就Louis個人的觀點而言，千萬不要將自己的角色侷限在程序設計師或系統管理員而排斥學習任何一方面的知識。因爲如此只會讓您在執行一些任務時捉襟見肘罷了。接下來就讓我們進入的正題吧!!
三、Notes資料庫的分類與基礎結構
在學習Notes AP開發的第一步驟，就是要先對Notes資料庫有所瞭解，如此纔不會因爲觀念不足或是錯誤而導致在開發過程中產生阻礙。所以Louis先整理一些觀念讓您稍微瞭解：
Top
（一）Notes資料庫的分類
以目前市場上的資料庫產品而言，就資料型態、功能性或配置方式分成好幾類，例如最常聽到的就是關聯式資料庫（RelationalDatabase），通常簡稱爲RDBMS或是RDB，而最具代表性的就是Oracle、DB2、Informix、SQL⋯等等，不過這都是要付授權費，如果是免費的，目前最紅的該屬MySQL了(Notes都可以跟這些資料庫整合喔~~)。
就資料型態而言，Notes屬於文件式資料庫而非關聯式資料庫。很多初學Notes的朋友對文件式資料庫這名詞通常都會很疑惑，一是因爲網路上很難找到相關信息，二是對Notes還不是很瞭解。不過在之後的內容中Louis會陸續說明文件的觀念。
就資料庫的配置方式而言，Notes則被歸類在分佈式資料庫，爲什麼呢？因爲Notes
的資料庫可以藉由抄寫機制，將各資料庫抄本分置到各服務器與客戶端中。分佈式資料庫的理論在網路上有很多資料，若有興趣的話可以到各大搜尋引擎網站找找。
（二）Notes資料庫的結構
每一個Notes資料庫在windows OS下是以檔案格式存在的，其擴展名通常是NSF，也就是Notes StorageFacility的簡寫，翻譯成中文就是Notes儲存設備。至於擴展名NTF也是Notes範本資料庫，全名是Notes TemplateFacility，是用來產生一般資料庫的範本。也就是說，您可以利用模板資料庫來新建一個資料庫，而此資料庫中的設計是與模板資料庫的設計一模一樣的。
按照官方的說法，每個Notes資料庫是由四個基本組件所組成：
1.ACL：
就是Access Control List，一般翻譯成存取控制清單，或是權限控制清單，顧名思義就是讓資料庫管理員可以指定使用者對該資料庫執行何種動作。
2.設計組件：
是指套表、視界、外框、圖文框、領航員⋯等等組件，而這些都是Notes資料庫最最基礎的組件，也是用來讓資料庫可以與使用者互動的基本組件，沒有這些組件，資料庫即無法運作。
3.所謂邏輯：
是指程序設計師在資料庫中所撰寫的程序語言，Lotus Script、公式、代理程序都是。主要是要運算處理資料庫中的資料，或者達成某些自動化的作業。
4.資料：
是指儲存在文件中的文字、數字、日期時間、附加檔案⋯等等信息。
四、資料的安全控管
若要簡單描述Domino對資料的安全控管，基本上由外而內可以分成幾關：服務器è資料庫è文件è隱藏公式。
以服務器這一關來說，是在服務器文件中控管的，例如允許或不允許哪些使用者存取此服務器、允許或不允許哪些使用者可以在服務器上建立或刪除資料庫…等等。
若是使用者被賦予存取服務器的權限，就會進入到資料庫安全控管這關，而這關的安全控管就是由資料庫ACL來決定的。
再來是文件的安全性控管，這是經由套表屬性之安全卷標下的選項，以及讀者與作者欄位來處理的。
最後就是隱藏公式，其實，隱藏公式根本就不算是安全性控管的方法，這隻能說是開發技巧。因爲即使透過隱藏公式把套表中的特定欄位隱藏起來，使用者仍然可以透過文件屬性方塊看到各欄位中的資料。
Top
五、ACL
既然我們在前面多次談到ACL，不稍微跟他交個朋友好像說不過去，所以在這兒就爲大夥兒引薦他吧，呵呵。在ACL中主要有幾種組件設定：使用者類型、權限類型、執行動作。
設定使用者類型是爲了避免ID被誤用。舉例來說，通常服務器在資料庫ACL中都是管理員權限，假設服務器ID被有心人士盜用，可能就會造成極大的破壞。所以爲了防範有心「人」士進行這種破壞行動，就必須在ACL中正確設定爲服務器類型，如此該人士即使拿到服務器ID也沒辦法使用Notesclient來對資料庫執行任何活動。因爲，服務器不是「人」，所以不會使用Notesclient（不過在系統管理中，Louis強烈建議把服務器當作是「人」，這樣有助於管理概念的建立）。但相對的，如果未設定適當的類型，也會導致某些動作無法執行。
再來是權限類型，依權限低高依序有七層－沒有權限、儲存者、讀者、作者、編輯者、設計師、管理員。【沒有權限】當然就不能對資料庫執行任何動作，因爲連進去的權利都沒有。Louis常戲稱【儲存者】爲工讀生權限，儲存者僅能輸入資料到資料庫中，輸入完畢後，就無法再看到這些資料。感覺就像找了一位工讀生來key in大量資料到資料庫中，但又不想讓工讀生記起這些資料或是看到其它資料。
先假設文件或套表中沒有讀者欄位，當使用者被賦予【讀者】權限時，使用者就只能閱讀文件，而不能編輯文件，當然更不可能建立文件（可執行動作之建立文件選項被強制disable了）。不過，一但文件中有讀者欄位，若使用者的名稱未在讀者欄位的名稱清單之中，則即使有再高的ACL權限還是無法閱讀該文件。
至於【作者】權限就必須跟【作者】欄位配合使用才具效用，當使用者被賦予【作者】權限，但作者欄位中的使用者名稱卻是別位使用者時，這時即使該份文件是目前使用者所建立，但因爲其名稱未列於作者欄位中，所以無法編輯該文件，僅能閱讀而已。順帶一提，如果使用者被賦予【編輯者】(含)以上權限，但文件中的作者欄位中並沒有這位使用者名稱，使用者還是可以編輯文件，因爲【作者】權限必須跟【作者】欄位配合使用才具效用，也就是說【編輯者】(含)以上權限不受作者欄位的約束。
至於【設計師】權限就是多了使用Domino Designer來開發AP的權限。而管理員則是多了修改ACL的權限。
茲概略整理下表以供參考：
管理者 設計者 編輯者 作者 讀者 儲存者 沒有權利
ACL設定 V
建立修改設計組件 V V
編輯所有文件 V V V
編輯自已文件 V V V V
增加新文件 V V V V V
讀取所有文件 V V V V V
在資料庫建立時，會在ACL的使用者清單中看到-Default-這筆項目。-Default-的作用是，當使用者在ACL中找不到適用於自己的權限時，就套用-Default-的權限。也就是說，凡名稱未明列在ACL中或未包含在ACL的羣組中，就套用-Default-的權限。在開發AP時若無特殊需求，-Default-通常都設定爲編輯者。
您還會看到LocalDomainServers羣組與OtherDomainServers羣組。顧名思義，只要是與目前資料庫的所在服務器位在同一Domino網域的服務器都會自動包含在LocalDomainServers羣組中，除非您去names.nsf中更改此羣組文件，那又另當別論了Orz。所以此羣組預設權限是管理員，主要是爲了讓相同網域內的服務器可以進行抄寫作業。至於OtherDomainServers羣組就是跟LocalDomainServers相反了，因爲此羣組的成員均爲不同網域外的Domino服務器，而且預設是無權限。有些集團企業因爲有一個以上的Domino網域，所以可能會利用此羣組來達到某些跨網域存取的需求。不過，在達成此類需求時，請先手動把那些位於不同網域的服務器名稱加到names.nsf中的OtherDomainServers羣組文件喔。
最後要談到Anonymous這個特殊項目，這是要手動新增給Web AP使用的。也就是當未透過Web ID &Password登入的使用者，均會被視爲匿名者並套用Anonymous項目的權限。若WebAP未設定此項目時，當您使用瀏覽器開啓資料庫時，系統就會給您一個警告，要求您到ACL中新增此一項目喔。請特別注意，在開發WebAP時若無特殊需求，請將此項目設爲無權限，否則您資料庫中的資料可能就會在網路上趴趴造了~~。
七、Notes應用系統
在進入開發組件的正題之前，我們先來聊聊什麼是Notes應用系統。通常Notes應用系統也稱爲Notes應用程序、NotesAP…等等。儘管這些名詞都不同，但其實都是指使用DominoDesigner這個設計接口所開發出來的系統，像是請假系統、加班申報系統、請採購系統、文具申購系統、ISO文件管理系統，甚至是ECN系統、NBR系統…等等都屬之。我想稍微列出這些系統名稱，應該就可以稍微明瞭Notes不是隻能用來當作電子郵件系統了吧。
一般初學者在還沒開始真正瞭解Notes應用系統時，通常會認爲一個資料庫就是一支Notes應用系統。其實不盡然如此，絕大部分的Notes應用系統都是由一個以上的資料庫所組成。
舉例來說好了，就Louis的經驗，建議剛導入Notes而且要開始開發系統時，第一優先開發的應該是人員組織資料庫，這個資料庫主要在儲存企業人員組織信息，像是部門文件與人員文件。爲什麼要先開發建置這資料庫呢??因爲使用者在許多系統的窗體中，都有申請人的姓名、部門、工號…等等基本信息欄位，而這些欄位值強烈建議不要讓使用者輸入，而是由程序去人員組織資料庫中自動搜尋並帶出的（通常是利用@UserName取得的Notes名稱來當作關鍵值）。所以，拿請假系統來說好了，既然請假系統會跨資料庫到人員組織資料庫取值，這就算是由兩個資料庫來組成一個請假系統了。
當然，上述的例子是比較小型的例子，若要說又大型又比較有名的例子就屬Lotus Workflow了，因爲其每一支系統都至少要有三個資料庫所組成－應用程序資料庫、人員組織資料庫、過程定義資料庫、設計儲存資料庫（選擇性）。
所以總結來說，一支Notes應用系統可以由一個或一個以上的Notes資料庫所組成。
注：若您對人員組織資料庫沒有什麼觀念的話，可以參考DominoClub網站的SnowMan專欄中的簡易員工資料庫。雖然SnowMan兄謙虛的說那是「簡易」員工資料庫，不過其實該有的基本組件都已經有了，可說是麻雀雖小五臟俱全。各位只要依據各公司自己的需求再添加欄位就可以很完整了。網址如下：
http://www.domino.idv.tw/bbs/bbs2002...B?OpenDocument
八、欄位－Item與Field
應該會有朋友覺得奇怪，爲何Louis不是先介紹文件或是套表，反而是先介紹欄位呢??其實我在下筆時也有考慮過這問題，之後一方面認爲如果先講文件與套表，可能要花比較多的時間與篇幅寫；另一方面覺得欄位是最基礎的觀念，而且在說明欄位觀念時也會稍微補充套表與文件的觀念，所以決定先說明欄位。
Item與Field的中文翻譯通常都是「欄位」，所以常被搞混，但兩者其實是完全不同的。嚴格來說，Item是要透過文件屬性方塊纔可以看到的後端欄位；Field則是在套表上才能看到的前端欄位。以下是針對兩者的特性期之間的關連性加以說明：
Top
（一）Item
Notes資料在儲存上最基本的容器就是item。它可以儲存文字、數字、日期時間、附加檔案⋯等等資料。也由於是儲存容器，所以要在文件儲存後纔會產生，若文件還沒儲存是不會有Item存在的，您可以試着開啓一份新文件，然後打開文件屬性方塊看看就知道了。所以簡而言之，文件其實就是由item所組成的。Item本身也有其屬性，例如儲存在item中的資料長度、資料類型⋯等等。而這些也可以從文件屬性方塊看到。
（二）Field
至於Field，簡單來說，在新文件上是要讓使用者輸入資料；而在已存在的文件上，則是用來顯示及編輯已儲存於Item中的資料，所以稱之爲前端欄位，也就是說Field是用來與使用者互動的一個設計組件。既然是與使用者互動的設計組件，那就一定有某些方法可以達成此目的，就是透過field的程序，像是默認值公式、轉譯公式、驗證公式、數個事件都可以讓程序設計師撰寫程序以達到上述的互動目的。
（三）Item與Field的連結
既然item是後端欄位，field是前端欄位，那就一定有方法將兩者連結起來。舉例來說，在一般狀況下，若在套表上有一個名爲X1的field，當文件儲存時，在此欄位中的數值就會儲存到名爲X1的item中。再假設一種狀況，假設套表上有一個名爲X1的field，在文件中另有一個名爲Y1的item，若要將Y1的數值顯示在X1 field的話，只要在X1 field的默認值公式或是計算公式填入Y1這個item名稱即可。
（四）LotusScript的Item與Field
因爲這種前後端結構的觀念，所以在LotusScript中的NotesDocument類別下提供幾個方法來操作處理item，像是GetFirstItem、GetItemValue…等等。如果程序設計師想要進一步處理item，則可以使用NotesItem的類別。這類後端的類別與方法通常是用來處理item中的數值。
至於操作處理Field的相關方法則被放在NotesUIDocument前端類別中，像是FieldGetText、FieldSetText⋯等等。這類前端的類別與方法通常是用來與使用者達到互動。
九、套表
就官方的定義而言，套表是用來顯示動態信息的。既然是顯示動態信息，就表示其中的信息是要讓使用者可以看的到，更深入一點，就是讓使用者可以透過套表來跟資料庫中的資料作互動。所以套表在Notes中真的佔有很重要的地位，而且應用層面甚廣，例如，單純顯示文件中的信息、讓使用者輸入資料以建立文件、編輯文件中的資料以更新信息、在套表事件或是其它組件加入程序以運算處理文件中的資料…等等。在ND6中則可以直接查詢RDB中的資料。ND7開始更可以和DB2資料庫做資料交易。
但是，回到原點，沒有任何其它設計組件存在的空套表是沒有實質意義的。所以當套表中存在field、按鈕、動作按鈕、小節、焦點信息、有程序的事件…等等設計組件，才能發揮出套表的功效。相對於文件是許多item的容器，套表則是許多設計組件的容器。例如在Web上可以在套表中嵌入視界來美化視界在Web上的呈現。
再回到套表最主要的功能－建立與編輯文件。就建立新文件而言，當使用者在各field中輸入數值並儲存以後就會產生一份文件，而field中的數值則會儲存到該文件中的各item中。另一方面，當使用者利用套表開啓已經存在的文件時，套表的field通常就是用來顯示或編輯item的數值。
Top
十、文件
其實在上述中差不多已經把欄位、套表、文件的關係解釋的差不多了。所以在這兒我們就只稍做補充。
由於Item無法自行存在，而是必須存在於文件中，所以換言之，Notes文件可以說是包含一個以上Item的集合，這可說是一個抽象的觀念。其實有些人會認爲視界有顯示出來或是套表可以打開的纔算是文件，但其實不然，因爲文件也有可能是「隱藏」在資料庫中而不顯示的。這就是常有人會看到工作區的資料庫顯示有未閱讀文件，但又在視界中找不到的原因。
另外，也有些人會認爲文件跟套表是一體的，事實上也不然，套表與文件是分開的，就如同先前曾經提到，套表是爲了讓使用者可以新增、編輯、顯示文件的。但也有例外，如果在套表屬性中有勾選文件與套表一起儲存的屬性時，文件與套表就會儲存在一起，但通常不建議如此做。因爲把套表中的所有設計組件與文件合併儲存在一起，就會讓文件的體積變大，進而佔用硬盤空間。就像是本來只有55公斤的Louis穿上幾件衣服後，可能就增加到57公斤了。
另外，在Notes中還有一種特殊文件，就是設計文件，也就是開發者開發出來的設計組件，像是套表、視界…等等，也是以文件型態存在的，這些文件統稱爲Design Notes，不過當然也可以稱爲Design Document。在DominoDesigner的設計組件清單中，使用滑鼠右鍵單擊任一組件，都可以看到該設計組件的文件屬性。順帶一提，在早期Notes文件並不稱爲Document，而是稱爲note，所以纔有Lotus Notes這名字出現。
但是把話說回來，因爲Notes文件的資料並無法像關聯式資料庫可以利用key值把各資料做互相關聯，所以產生一些資料處理上的不便。不過這類問題通常還是可以經由技術上來解決的。而且也因爲如此，Notes才能成爲各種關聯式資料庫的整合接口，不是嗎 ^_^
十一、自我提升
當我寫下這個標題時感覺有點心虛，因爲好像在灌水，呵呵。不過相信接下來Louis所說的，絕對是讓各位初學者非常受用的。
一般剛開始開發NotesAP時，相信大部分使用者提出的需求都是主管去談的，而您絕對是傷透腦筋在想功能寫程序的那個人。雖然這是很一般的程序，但對於您的未來其實不見得是好處。雖然可以寫出一支令使用者滿意的AP絕對是一件很了不起的事，但是當您完成這支AP以後除了學到很多程序技巧與成就感以外，您還獲得了什麼？這是非常值得思考的一件事。
Notes的精髓在於籤核流程的開發，而籤核流程的精髓則是各產業的Domain KnowHow，也就是各產業的專業知識。所以當您接下主管交付的需求後，並非一味的埋頭苦思程序該怎寫、功能該怎開發，更重要的是去了解此係統的真正目的是什麼、流程爲什麼要這麼跑、使用者在籤核底下的作業是什麼。所以您應該再找機會去跟提出需求的使用者瞭解他們的作業程序，進而從他們的腦袋裡學習他們領域的專業知識。
其實，我常常在跟使用者談需求的時候，即使懂也裝不懂，很有禮貌的請使用者重頭講一次，反正被罵笨也無所謂，因爲目的已經達到，大不了晚上抱着枕頭哭一下就好了，隔天又是好漢一條，哈哈。
當您在各產業待過以後，這些知識就會逐月逐年累積成爲您的寶藏。而這些寶藏將會在以後成爲您闖蕩江湖的寶刀。因爲往後當您在與使用者談需求時，由於您的寶藏取之不絕用之不盡，頻頻點頭稱是的將不再是您而會是使用者。
我相信應該很少朋友希望自己永遠靠寫程序維生，尤其到了一定年紀以後，寫程序反而是一種負擔。所以接下來賴以維生的將會是您的Domain KnowHow，幫您賺錢的絕對是您的腦袋與口才，而不是寫程序的技術。這時應該要很高興您不是修計算機的信息人員，而是寫Notes的人員。所以，趁現在趕快累積您未來的財富吧!!加油!! 加油!! Go!! Go!! Go!!
嗯..還沒結尾..請繼續閱讀..感恩Orz
十二、視界
在隨筆（二）中，Louis跟各位討論到文件與套表的關係，所以接下來，我們就來談談視界吧。
視界這個設計組件，很多人都會把它拿來跟RDB（關聯式資料庫）的table作比較。其實是有那麼點像，所以在ND7纔會改良出SQLQuery視界這玩意兒。不過，撇開視界與table的比較，視界的主要功能是爲了有系統的整理資料庫中的一大堆文件，將這些文件中的關鍵信息分門別類的「顯示」出來，好讓使用者可以快速找到他們所需要的信息。所以您要說視界是由一大堆文件所組成也不爲過。但因爲是給使用者使用的，所以在設計一個視界的時候，最好可以先與使用者討論清楚，否則被要求重排視界的可能性非常的大。
不過，若從設計面來看，視界應該說是由直欄所組成，畢竟沒有直欄的視界是沒有任何用處的。在前面，我曾經把「顯示」這兩個字特別標出來的原因是，直欄除了可以直接顯示文件的欄位值以外，您也可以透過直欄公式來處理多個欄位值後再將其顯示出來。也就是說，處理過後的直欄值並非儲存在文件中，而僅供「顯示」。優點在於，您不用在文件中放一大堆計算欄位來儲存一些只爲了「顯示」用的數值。但缺點是，若直欄中有太多的計算公式，則視界的負擔就會加重，因爲它必須要計算每份文件的欄位值。當文件數量很多時，其負擔是可想而知的。
我想大部份的初學朋友都知道「視界選擇」這玩意兒吧，這玩意兒講明白一點就是透過您指定的條件來篩選要顯示在此視界的文件。最不嚴謹的條件當屬【select @all】，因爲它會將資料庫中所有的文件通通顯示在此視界中。最常看到的條件應該是【selectform=”套表名”】，視界會根據您所指定的套表名來搜尋並顯示使用此套表建立的文件。當然您也可以搭配更多的條件設定來更進一步篩選文件，像是某個欄位等於、大於，或小於某個值。
有人可能會發現在「視界選擇」下面有個「套表公式」，Louis曾經遇到一位我覺得還不錯的程序設計師，但他卻從來沒用過「套表公式」。這真的是很重要的功能，但我要在此賣個關子，之後會搭配其它功能來說明。
另外，如果您已經熟悉公式與LotusScript的話，相信您一定常用到@DBLookup、@DBColumn、GetDocumentByKey、GetEntryByKey…等等搜尋類函式與方法。使用這類程序的第一要件當然就是要把視界中的第一直欄設定爲排序。不過，Louis要講的重點不是這個，我要講的是…ㄜ…忘記要講啥了…果然年紀到了就是會這樣..><..（一分鐘後）對了!!我要講的是…當您在設計視界時，請儘量將程序用的視界與使用者用的視界分開，因爲當資料庫中有很多視界時，若您共享這兩種視界又沒特別註明的話，哪天使用者要求您重排視界，結果運氣不好的您移動到程序用視界的第一直欄，那就糗大了，因爲一定會有程序找不到符合的關鍵詞資料，而這很有可能讓您花上大半天去找蟲蟲何在。至於要怎標示，把視界名稱括號起來就好了，要不就在視界屬性的註明欄位註明。不過Louis偏好前者，因爲前者可以把視界隱藏起來，也就是說，當使用者按下【檢視】【移至】也看不到那個視界，除非他們知道按下Ctrl + Shift +【檢視】【移至】（又學一招了吧，呵呵）。
既然剛剛提到GetDocumentByKey與GetEntryByKey這兩個method，就順便提一下這兩者的差別。如果您曾使用偵錯器觀察的話，就會發現前者是傳回文件對象，所以理所當然會把文件中的所有欄位值還有一堆屬性通通抓出來，而後者就只會抓到視界中直欄值。這有什麼影響嗎？當然有影響囉！使用GetDocumentByKey與GetEntryByKey可能還察覺不出來，當您使用GetAllDocumentsByKey與GetAllEntriesByKey來傳回上百筆的資料，相信您就可以察覺到Server Loading的不同了。
十三、資料夾
既然談到視界，就不得不來談資料夾。這裡的資料夾當然不是指Windows的資料夾，Louis要說的是Notes的設計組件之一的那個資料夾。資料夾跟視界非常之像，我們可以說它們是龍鳳胎也不爲過，因爲最明顯的差別在於”視界選擇”。ㄜ..沒有「視界選擇」那怎篩選文件啊！？既然沒有「視界選擇」當然就是有其它的方法可以篩選囉。資料夾篩選文件的方式可以透過程序或使用者手動篩選（複製或剪下，然後貼上）。換句話說，資料夾內的文件主要是由程序或使用者手動置入的。
資料夾應用的最徹底的當屬郵件資料庫了，收件匣各位應該很熟悉吧，它老兄就是資料夾而不是視界，從R5的郵件資料庫可能還看不太出來哪些是資料夾，哪些是視界，但從R6的郵件資料庫就比較容易分辨了，因爲它多了一個「視界」的展開項目，在裡面的全部都是視界。不過在「視界」的展開項目以外還是有視界的。若要真正去辨別的話，還是要從Notes Designer比較明確一點。
先來解釋「手動」放文件到數據夾的觀念吧。假設A視界與B視界的視界選擇條件一樣，其所篩選出來的文件其實都是同一份文件。但是，當您在C資料夾與D資料夾中各看到一份幾乎是一模一樣的文件，在資料庫中它們『可能』不是同一份文件，而是兩份文件，原因在於資料夾是獨立的個體，所以手動個別貼上的話就會是兩份文件。簡單來說，資料夾的文件是被「放」進去的，視界的文件是被「篩選」出來的。這樣您應該就懂了吧，再不懂，那就請您去郵件資料庫多玩幾次複製或剪下，然後到處貼上的遊戲囉。好吧，再雞婆舉例說明一下：
1.當您從A視界中複製一份文件，然後貼到C資料夾，此時C資料夾有一份文件，D資料夾會是空的，A視界則變成兩份文件。
2.再到D資料夾貼上那份文件，這時C資料夾還是隻有一份文件，D資料夾當然也只有一份文件。但是，回過頭來看原來的A視界，您會發現A視界中會變成三份文件。
3.這三份文件=原來的文件＋C資料夾的文件＋D資料夾的文件。其實從文件屬性中可以看到這三份文件的UNID其實是通通不一樣的。
以上都是手動放文件到數據夾的觀念，接下來就是「程序」放文件到數據夾的觀念了，使用NotesDocumentCollection.PutAllInFolder將文件放到數據夾中時，文件並沒有增加，因爲PutAllInFolder並不是「複製->貼上」文件，而是幫助數據夾「篩選」出符合條件的文件再「顯示」出來。所以來源視界與數據庫中的文件是不會增加的。
資料夾有一個很好用的功能－排序。當您使用GetAllDocumentsByKey從視界取得某些文件時（NotesDocumentCollection），這些文件並不會按照原視界的排序一份份排好，所以如果當您的需求是要「依照某種順序」來處理這些文件的話，您可以先建立一個資料夾，並將此資料夾的排序設定成您想要的，再用PutAllInFolder方法把文件通通「顯示」到裏面進去，這樣您的文件就會照順序排了。不過請記得，處理完請務必記得再使用RemoveAllFromFolder把那些文件從資料夾刪除。否則這資料夾中的文件會一直增加，這樣就會造成之後所處理的文件不是當次放進去的文件，而是累積已久雜七雜八的文件。
十四、隨處可得的文件
這一篇是要響應某位匿名朋友的問題－何謂前端文件、後端文件、屏幕上看到的文件、內存中的文件、數據庫中的文件？其實在前面幾篇中，已經有談到文件的觀念，不過沒有以這幾個項目來做區分說明就是了，所以這部份我們就當作再次溫習文件的觀念吧!!再者，路哥認爲這問題以一位初學朋友而言問得實在是很不錯。而這問題我相信也是衆多初學者的問題!!
1.後端文件
後端文件的產生基本上可以分成兩種－透過套表產生與透過程序產生。前者當然是由使用者開啓套表，並在相關字段輸入數據後「儲存」產生的。後者則是透過Lotus Script或Java產生的，例如Set doc = New NotesDocument(NotesDatabase)……Calldoc.Save(True,True)。您看看，這兩者都有「儲存」的程序喔，如果沒有儲存的程序，文件就不會在數據庫中產生。當文件進入到數據庫中時，我們就可以稱它們爲後端文件了。而在Lotus Script中是以NotesDocument類別來實現的。
所以，只要是已經經過儲存的文件，我們就可以統稱爲數據庫中的文件。
2.前端文件
至於前端文件就很簡單了，不管是新文件或是原本就已存在於數據庫中的文件，只要是透過套表呈現到屏幕上的就都叫做前端文件。所以其實屏幕上看到的文件就等於前端文件，其主要的作用在與使用者達到互動。在Lotus Script中則是以NotesUIDocument類別來實現的。
3.後端文件與前端文件的關係
同一份文件會不會同時擁有前端文件跟後端文件呢？答案是「不一定」。
在前面的隨筆中有提過，利用套表開啓一份新文件時（也就是前端文件），打開文件屬性方塊後是看不到什麼較實際的信息的，因爲還沒經過儲存程序，也就是說未儲存的新文件就只有前端文件。
但用套表開啓一份已存在於數據庫中的文件時，在屏幕上看到的就是前端文件，您在上面修修改改尚未儲存的數據均可視爲前端文件的部分。但此時開啓文件屬性方塊，您可以看到此文件的相關屬性與各字段數據，這部份則是屬於已儲存之後端文件的部份。若您在此時按下儲存，前端文件的數據就會更新到後端文件中了。這就是前端文件與後端文件並存狀況。
至於在Lotus Script中怎麼透過前端文件來取得後端文件呢？只要使用NotesUIDocument.Document即可，因爲NotesUIDocument代表目前開啓的前端文件，而Document則是指目前文件的後端文件。
4.內存中的文件
這部份麻，我想就跟Lotus Script或Java程序設計有關了，我儘量解釋您就儘量看看，能吸收多少算多少。
在LotusScript中有NotesDocument與NotesDocumentsCollection的物件。當您使用GetDocumentByKey方法取得NotesDocument對象，或是使用GetAllDocumentsByKey取得NotesDocumentsCollection的對象時，被取得之文件對象所包含的所有數據都會被儲存在內存中，等待您進一步的處理。
在前面路哥也提到過，若文件中有很多數據，則太多的文件就會造成內存的負擔，所以，如果您只是很單純的處理少數資料，就請儘量使用NotesViewEntry或NotesViewEntries，因爲內存只會儲存文件在此視界的直欄數據，而不會儲存文件的所有數據。
5.結論
文件是很抽象的觀念，我稍微將它具體化一下，但並非一模一樣。數據庫就類似公文櫃，視界就有點像是公文夾，文件類似現實生活中的公文。如果沒有公文夾視界來將文件分門別類的保存起來，數據庫就會像是一個擺放了一大堆雜亂無章文件的公文櫃。
我建議您可以再回到前面幾篇溫習一下，相信會有不同的感覺的。
十五、選擇開啓文件的套表
回到咱們的進度上吧，在本篇隨筆中，這一節算是唯一在進度上的一節。路哥好像沒有談到有進度吧，因爲進度在路哥的腦袋瓜子裏，呵呵。
相信各位在看過前三篇隨筆後，對文件跟套表的關係應該有一定程度的瞭解，所以接下來要爲各位介紹的是，當您開啓一份文件時Notes是如何決定要用哪一張套表來顯示文件。
不懂路哥在說什麼嗎？沒關係，我就再稍微解釋一下，Notes文件並非只能使用當初建立此文件的套表來開啓，也就是說一份文件可以使用不同的套表來開啓，而產生的結果就是在前端呈現的文件之排版與數據會不同。例如，有A與B兩張套表，A套表有兩個字段－AAA、BBB；B套表只有BBB字段。另外在數據庫中有一份文件儲存了AAA字段值111與BBB字段值222。這時使用A套表開啓甲文件時，您會看到屏幕上顯示111與222兩個字段值。接下來再用B套表開啓甲文件，此時您就只會看到222而已。也就是說同一份文件會因爲套表上的排版與字段不同而有不同的顯示。
用最最最簡單的實際例子來說明好了，假設路哥有兩條牛仔褲，A牛仔褲的左邊褲管剪了一個洞，而B牛仔褲則是在右邊褲管剪了一個洞，當路哥穿A牛仔褲時就會露出左膝蓋，穿B牛仔褲時則是露出右膝蓋。即使你們會因爲我穿不同的牛仔褲而看到不同的膝蓋，但其實路哥本身還是有兩個膝蓋，並不會因爲穿哪件牛仔褲而真的少了哪個膝蓋。不過……路媽要是看到我穿這種牛仔褲，一定又會念說，你是沒錢可以買褲子喔!! ><
好回到正題，Notes是如何決定要用哪張套表來開啓文件的。採用順序爲，套表與文件合併儲存à視界的套表公式à Form字段值à數據庫的預設套表。說明如下：
1.套表與文件合併儲存：這在隨筆2中的第3頁的倒數第三段有解說過，請自行回頭參考。
2.視界的套表公式：這個就要特別解釋了，因爲曾經有兩位從軟件公司出身的朋友同時問過我一個問題就是，如何在視界中依不同的條件來選擇不同套表開啓文件。其實滿驚訝的，因爲我覺得這是非常基礎的功能，而且是必須知道的。所以在此特別說明，答案是視界的套表公式，在哪兒呢？就在寫視界選擇公式下面的那個「套表公式」。
簡單來說，您可以寫一行程序，假設A字段值=1時就用A套表開啓，否則就用B套表開啓。所以當A字段值有所變動時就會使用不同的套表來開啓文件。個人覺得這功能雖然很少用，但是，卻是很好用的功能。
3.Form字段值：在Notes中有個保留字段叫做Form，而此字段值就是在儲存用來開啓文件之套表的名稱，所以強烈建議使用Lotus Script建立新文件時都要指定此字段值（語法：doc.Form=”套表名稱”）。
4.數據庫的預設套表：在套表的設計屬性的基礎卷標下有一個「預設的數據庫套表」選項，若勾選此選項後，前面所說的條件若都不成立時，就會採用勾選此選項的套表來開啓文件。我想應該會有朋友問說，那要是有兩張套表都有勾怎辦？那您就勾勾看吧，呵呵。一個數據庫只能存在一張預設套表，所以後勾的贏，也就是說若A套表勾了以後，B套表又勾，那系統就會自動取消A套表的該選項。
好，講到這邊整理一下，當您開啓一份文件時，Notes會先參照文件當初儲存時的那張套表是否有勾選「套表與文件合併儲存」屬性，若有則採用該套表開啓。若沒有就會參照視界的套表公式，所以若您有寫套表公式時就會依照該公式的條件來開啓文件。若沒有寫套表公式，那就會參照文件中的Form字段值，若文件中此字段值有指定套表名稱，就會使用該套表來開啓。若沒有則會參照最後的防線－「數據庫的預設套表」。若數據庫中沒有預設套表呢？如果路哥沒有記錯，系統好像會出現「找不到套表」之類的錯誤訊息。不過也有可能記錯喔，最近腦筋不太靈光…呵呵。
十六、Lotus Script超基礎觀念
這是路哥突發奇想的主題，相信初學者的您在看完此節以後，一定會非常有收穫唷!!
LotusScript是以對象爲基礎的程序語言，還談不上是完全對象導向的語言。市面上有很多書籍在談對象導向，好像一開始都是用車子或飛機來當例子，可是路哥總覺得缺少了什麼。所以長久以來路哥一直很想找出某種生活上的實際情形來與LotusScript中的類別對象相對照，讓初學者有很清楚的概念。在某天明月高掛的夜晚，終於讓路哥頓悟了，就只差沒成仙而已。因爲是新的想法，所以各位這次就當作是路哥的白老鼠吧，感恩不盡，若有講錯的地方還多多海函 Orz。
在開始之前，路哥先聲明不把所有的類別都拿出來講，我只用了幾個比較常用的類別，其餘的就交給各位自行體會了。讓我們開始吧!!
Lotus Script的特點之一，就是有很明確的對象階層，而且大部份每一階層對象皆會包含下一階層對象（NotesItem是最底層對象，所以只有方法與屬性）。
例如NotesSessionà NotesDatabaseà NotesViewàNotesDocumentà NotesItem。
精采的來了，我的虛擬實景是：
1.NotesSession = 地球，因爲地球是一個大環境，包容各式各樣的對象與數據。
2.NotesDatabase = 臺灣，因爲每個國家就像是一個數據庫，有很多的文件跟視界存在。
3.NotesView = 縣市行政區，每個縣市可以視爲一個view都是以現式的名稱來將位於各地的房子篩選出來，所以NotesDocument=房子，如下說明。
4.NotesDocument = 房子，因爲房子有很多數據，像是地址就可以比做是UNID，因爲地址絕對不會重複。
5.NotesItem = 房子的基本數據，透過GetFirstItem就可以得到類似房子有幾坪、戶口數、在第幾層…等等的信息。
所以呢，現在如果我們想要知道路哥房子的房間數，程序可以這樣寫：
Dim 地球 As New NotesSession
Dim 臺灣 As NotesDatabase
Dim 臺北縣 As NotesView
Dim 路哥的房子 As NotesDocument
Dim 房間數 As NotesItem
Set 臺灣 = 地球.CurrentDatabase
‘ 因爲我們現在在臺灣，所以就用CurrentDatabase
Set 臺北縣 = 臺灣.GetView(“臺北縣”)
‘ 假設臺北縣這個View是以戶長姓名爲第一直欄而且有排序
Set 路哥的房子 = 臺北縣.GetDocumentByKey(“路哥”)
‘ 既然是要找路哥的房子，當然Key值就是”路哥”囉
Set 房間數 = 路哥的房子.GetItem(“房間數”)
‘ 因爲要查路哥房子的房間數，所以就直接去找房間數這個字段，此時傳回值會
是3，因爲路哥的房子是三房兩廳。
舉一反三，如果要找路爸的房子呢（不是路霸喔，是路哥的老爹啦…哈哈），那就把Key值改成”路爸”，因爲路爸也住臺北縣囉，這樣就可以找到路爸的房子數據了。
如何，夠清楚吧，爲什麼路哥會想用這種方式解釋，是因爲這樣比較能夠感覺出Notes是文件式數據庫的感覺，至於市面上那些使用飛機、車子當作例子的書籍，我想作者們應該是爲了表達對象導向的觀念吧。
許多初學Lotus Notes（LotusNotes以下簡稱Notes）的朋友常常會因爲Notes學習範圍太廣、教育訓練課程太貴、中文資料太少⋯等等因素，而不知該從何開始入門學習。不過因爲這些因素而放棄的話，其實是非常之可惜的，畢竟Notes的功能及其整合性在羣組軟件領域中，仍然是領先其它羣組軟件的佼佼者。
Louis爲了讓許多初學Notes的朋友可以快速上手，所以決定着手撰寫此係列的文章，希望以最淺顯易懂的白話文來爲初學者建立Notes程序設計最基本的觀念（但會不會中斷不敢保證:p）。不過既然是「隨筆」，所以一些順序的編排就不會那麼的有系統。另外，在章文中雖然偶爾會提到一些技術觀念，但並不屬於高深的技術文件，純粹只是觀念養成的文章。若您想進一步瞭解文中提及的觀念時，Louis「強烈」建議直接參考Notes程序設計說明資料庫。當然，本系列文章中若有訛誤還請各位前輩高手多多指教。
二、Notes學習方向
Notes的學習方向主要分爲程序設計與系統管理兩部份，一般通稱爲Notes AD（ApplicationDevelopment）與SA（SystemAdministration），而這也是IBM官方的說法。不過，有時候AD也有人稱爲AP，而SA則常會與IT界常用的系統分析（SystemAnalysis）搞混，所以在與其它朋友交流時可千萬不要雞同鴨講。
但不論是NotesAD還是SA的知識，這兩者並無明確界線，而且兩者其實是相輔相成的。以ACL的設定來講，就無法明確歸納至AD或SA任一範疇，因爲不管是在開發應用程序（應用程序以下簡稱AP）或是管理Domino系統，ACL的設定都是必須的常識。另外，在開發WebAP時，爲了讓瀏覽器使用者可以正常瀏覽存取Web AP的內容與資料，也須要先在服務器上做一些設定，而這也是開發人員所須要瞭解的。
所以就Louis個人的觀點而言，千萬不要將自己的角色侷限在程序設計師或系統管理員而排斥學習任何一方面的知識。因爲如此只會讓您在執行一些任務時捉襟見肘罷了。接下來就讓我們進入的正題吧!!
三、Notes資料庫的分類與基礎結構
在學習Notes AP開發的第一步驟，就是要先對Notes資料庫有所瞭解，如此纔不會因爲觀念不足或是錯誤而導致在開發過程中產生阻礙。所以Louis先整理一些觀念讓您稍微瞭解：
Top
（一）Notes資料庫的分類
以目前市場上的資料庫產品而言，就資料型態、功能性或配置方式分成好幾類，例如最常聽到的就是關聯式資料庫（RelationalDatabase），通常簡稱爲RDBMS或是RDB，而最具代表性的就是Oracle、DB2、Informix、SQL⋯等等，不過這都是要付授權費，如果是免費的，目前最紅的該屬MySQL了(Notes都可以跟這些資料庫整合喔~~)。
就資料型態而言，Notes屬於文件式資料庫而非關聯式資料庫。很多初學Notes的朋友對文件式資料庫這名詞通常都會很疑惑，一是因爲網路上很難找到相關信息，二是對Notes還不是很瞭解。不過在之後的內容中Louis會陸續說明文件的觀念。
就資料庫的配置方式而言，Notes則被歸類在分佈式資料庫，爲什麼呢？因爲Notes
的資料庫可以藉由抄寫機制，將各資料庫抄本分置到各服務器與客戶端中。分佈式資料庫的理論在網路上有很多資料，若有興趣的話可以到各大搜尋引擎網站找找。
（二）Notes資料庫的結構
每一個Notes資料庫在windows OS下是以檔案格式存在的，其擴展名通常是NSF，也就是Notes StorageFacility的簡寫，翻譯成中文就是Notes儲存設備。至於擴展名NTF也是Notes範本資料庫，全名是Notes TemplateFacility，是用來產生一般資料庫的範本。也就是說，您可以利用模板資料庫來新建一個資料庫，而此資料庫中的設計是與模板資料庫的設計一模一樣的。
按照官方的說法，每個Notes資料庫是由四個基本組件所組成：
1.ACL：
就是Access Control List，一般翻譯成存取控制清單，或是權限控制清單，顧名思義就是讓資料庫管理員可以指定使用者對該資料庫執行何種動作。
2.設計組件：
是指套表、視界、外框、圖文框、領航員⋯等等組件，而這些都是Notes資料庫最最基礎的組件，也是用來讓資料庫可以與使用者互動的基本組件，沒有這些組件，資料庫即無法運作。
3.所謂邏輯：
是指程序設計師在資料庫中所撰寫的程序語言，Lotus Script、公式、代理程序都是。主要是要運算處理資料庫中的資料，或者達成某些自動化的作業。
4.資料：
是指儲存在文件中的文字、數字、日期時間、附加檔案⋯等等信息。
四、資料的安全控管
若要簡單描述Domino對資料的安全控管，基本上由外而內可以分成幾關：服務器è資料庫è文件è隱藏公式。
以服務器這一關來說，是在服務器文件中控管的，例如允許或不允許哪些使用者存取此服務器、允許或不允許哪些使用者可以在服務器上建立或刪除資料庫…等等。
若是使用者被賦予存取服務器的權限，就會進入到資料庫安全控管這關，而這關的安全控管就是由資料庫ACL來決定的。
再來是文件的安全性控管，這是經由套表屬性之安全卷標下的選項，以及讀者與作者欄位來處理的。
最後就是隱藏公式，其實，隱藏公式根本就不算是安全性控管的方法，這隻能說是開發技巧。因爲即使透過隱藏公式把套表中的特定欄位隱藏起來，使用者仍然可以透過文件屬性方塊看到各欄位中的資料。
Top
五、ACL
既然我們在前面多次談到ACL，不稍微跟他交個朋友好像說不過去，所以在這兒就爲大夥兒引薦他吧，呵呵。在ACL中主要有幾種組件設定：使用者類型、權限類型、執行動作。
設定使用者類型是爲了避免ID被誤用。舉例來說，通常服務器在資料庫ACL中都是管理員權限，假設服務器ID被有心人士盜用，可能就會造成極大的破壞。所以爲了防範有心「人」士進行這種破壞行動，就必須在ACL中正確設定爲服務器類型，如此該人士即使拿到服務器ID也沒辦法使用Notesclient來對資料庫執行任何活動。因爲，服務器不是「人」，所以不會使用Notesclient（不過在系統管理中，Louis強烈建議把服務器當作是「人」，這樣有助於管理概念的建立）。但相對的，如果未設定適當的類型，也會導致某些動作無法執行。
再來是權限類型，依權限低高依序有七層－沒有權限、儲存者、讀者、作者、編輯者、設計師、管理員。【沒有權限】當然就不能對資料庫執行任何動作，因爲連進去的權利都沒有。Louis常戲稱【儲存者】爲工讀生權限，儲存者僅能輸入資料到資料庫中，輸入完畢後，就無法再看到這些資料。感覺就像找了一位工讀生來key in大量資料到資料庫中，但又不想讓工讀生記起這些資料或是看到其它資料。
先假設文件或套表中沒有讀者欄位，當使用者被賦予【讀者】權限時，使用者就只能閱讀文件，而不能編輯文件，當然更不可能建立文件（可執行動作之建立文件選項被強制disable了）。不過，一但文件中有讀者欄位，若使用者的名稱未在讀者欄位的名稱清單之中，則即使有再高的ACL權限還是無法閱讀該文件。
至於【作者】權限就必須跟【作者】欄位配合使用才具效用，當使用者被賦予【作者】權限，但作者欄位中的使用者名稱卻是別位使用者時，這時即使該份文件是目前使用者所建立，但因爲其名稱未列於作者欄位中，所以無法編輯該文件，僅能閱讀而已。順帶一提，如果使用者被賦予【編輯者】(含)以上權限，但文件中的作者欄位中並沒有這位使用者名稱，使用者還是可以編輯文件，因爲【作者】權限必須跟【作者】欄位配合使用才具效用，也就是說【編輯者】(含)以上權限不受作者欄位的約束。
至於【設計師】權限就是多了使用Domino Designer來開發AP的權限。而管理員則是多了修改ACL的權限。
茲概略整理下表以供參考：
管理者 設計者 編輯者 作者 讀者 儲存者 沒有權利
ACL設定 V
建立修改設計組件 V V
編輯所有文件 V V V
編輯自已文件 V V V V
增加新文件 V V V V V
讀取所有文件 V V V V V
在資料庫建立時，會在ACL的使用者清單中看到-Default-這筆項目。-Default-的作用是，當使用者在ACL中找不到適用於自己的權限時，就套用-Default-的權限。也就是說，凡名稱未明列在ACL中或未包含在ACL的羣組中，就套用-Default-的權限。在開發AP時若無特殊需求，-Default-通常都設定爲編輯者。
您還會看到LocalDomainServers羣組與OtherDomainServers羣組。顧名思義，只要是與目前資料庫的所在服務器位在同一Domino網域的服務器都會自動包含在LocalDomainServers羣組中，除非您去names.nsf中更改此羣組文件，那又另當別論了Orz。所以此羣組預設權限是管理員，主要是爲了讓相同網域內的服務器可以進行抄寫作業。至於OtherDomainServers羣組就是跟LocalDomainServers相反了，因爲此羣組的成員均爲不同網域外的Domino服務器，而且預設是無權限。有些集團企業因爲有一個以上的Domino網域，所以可能會利用此羣組來達到某些跨網域存取的需求。不過，在達成此類需求時，請先手動把那些位於不同網域的服務器名稱加到names.nsf中的OtherDomainServers羣組文件喔。
最後要談到Anonymous這個特殊項目，這是要手動新增給Web AP使用的。也就是當未透過Web ID &Password登入的使用者，均會被視爲匿名者並套用Anonymous項目的權限。若WebAP未設定此項目時，當您使用瀏覽器開啓資料庫時，系統就會給您一個警告，要求您到ACL中新增此一項目喔。請特別注意，在開發WebAP時若無特殊需求，請將此項目設爲無權限，否則您資料庫中的資料可能就會在網路上趴趴造了~~。
七、Notes應用系統
在進入開發組件的正題之前，我們先來聊聊什麼是Notes應用系統。通常Notes應用系統也稱爲Notes應用程序、NotesAP…等等。儘管這些名詞都不同，但其實都是指使用DominoDesigner這個設計接口所開發出來的系統，像是請假系統、加班申報系統、請採購系統、文具申購系統、ISO文件管理系統，甚至是ECN系統、NBR系統…等等都屬之。我想稍微列出這些系統名稱，應該就可以稍微明瞭Notes不是隻能用來當作電子郵件系統了吧。
一般初學者在還沒開始真正瞭解Notes應用系統時，通常會認爲一個資料庫就是一支Notes應用系統。其實不盡然如此，絕大部分的Notes應用系統都是由一個以上的資料庫所組成。
舉例來說好了，就Louis的經驗，建議剛導入Notes而且要開始開發系統時，第一優先開發的應該是人員組織資料庫，這個資料庫主要在儲存企業人員組織信息，像是部門文件與人員文件。爲什麼要先開發建置這資料庫呢??因爲使用者在許多系統的窗體中，都有申請人的姓名、部門、工號…等等基本信息欄位，而這些欄位值強烈建議不要讓使用者輸入，而是由程序去人員組織資料庫中自動搜尋並帶出的（通常是利用@UserName取得的Notes名稱來當作關鍵值）。所以，拿請假系統來說好了，既然請假系統會跨資料庫到人員組織資料庫取值，這就算是由兩個資料庫來組成一個請假系統了。
當然，上述的例子是比較小型的例子，若要說又大型又比較有名的例子就屬Lotus Workflow了，因爲其每一支系統都至少要有三個資料庫所組成－應用程序資料庫、人員組織資料庫、過程定義資料庫、設計儲存資料庫（選擇性）。
所以總結來說，一支Notes應用系統可以由一個或一個以上的Notes資料庫所組成。
注：若您對人員組織資料庫沒有什麼觀念的話，可以參考DominoClub網站的SnowMan專欄中的簡易員工資料庫。雖然SnowMan兄謙虛的說那是「簡易」員工資料庫，不過其實該有的基本組件都已經有了，可說是麻雀雖小五臟俱全。各位只要依據各公司自己的需求再添加欄位就可以很完整了。網址如下：
http://www.domino.idv.tw/bbs/bbs2002...B?OpenDocument
八、欄位－Item與Field
應該會有朋友覺得奇怪，爲何Louis不是先介紹文件或是套表，反而是先介紹欄位呢??其實我在下筆時也有考慮過這問題，之後一方面認爲如果先講文件與套表，可能要花比較多的時間與篇幅寫；另一方面覺得欄位是最基礎的觀念，而且在說明欄位觀念時也會稍微補充套表與文件的觀念，所以決定先說明欄位。
Item與Field的中文翻譯通常都是「欄位」，所以常被搞混，但兩者其實是完全不同的。嚴格來說，Item是要透過文件屬性方塊纔可以看到的後端欄位；Field則是在套表上才能看到的前端欄位。以下是針對兩者的特性期之間的關連性加以說明：
Top
（一）Item
Notes資料在儲存上最基本的容器就是item。它可以儲存文字、數字、日期時間、附加檔案⋯等等資料。也由於是儲存容器，所以要在文件儲存後纔會產生，若文件還沒儲存是不會有Item存在的，您可以試着開啓一份新文件，然後打開文件屬性方塊看看就知道了。所以簡而言之，文件其實就是由item所組成的。Item本身也有其屬性，例如儲存在item中的資料長度、資料類型⋯等等。而這些也可以從文件屬性方塊看到。
（二）Field
至於Field，簡單來說，在新文件上是要讓使用者輸入資料；而在已存在的文件上，則是用來顯示及編輯已儲存於Item中的資料，所以稱之爲前端欄位，也就是說Field是用來與使用者互動的一個設計組件。既然是與使用者互動的設計組件，那就一定有某些方法可以達成此目的，就是透過field的程序，像是默認值公式、轉譯公式、驗證公式、數個事件都可以讓程序設計師撰寫程序以達到上述的互動目的。
（三）Item與Field的連結
既然item是後端欄位，field是前端欄位，那就一定有方法將兩者連結起來。舉例來說，在一般狀況下，若在套表上有一個名爲X1的field，當文件儲存時，在此欄位中的數值就會儲存到名爲X1的item中。再假設一種狀況，假設套表上有一個名爲X1的field，在文件中另有一個名爲Y1的item，若要將Y1的數值顯示在X1 field的話，只要在X1 field的默認值公式或是計算公式填入Y1這個item名稱即可。
（四）LotusScript的Item與Field
因爲這種前後端結構的觀念，所以在LotusScript中的NotesDocument類別下提供幾個方法來操作處理item，像是GetFirstItem、GetItemValue…等等。如果程序設計師想要進一步處理item，則可以使用NotesItem的類別。這類後端的類別與方法通常是用來處理item中的數值。
至於操作處理Field的相關方法則被放在NotesUIDocument前端類別中，像是FieldGetText、FieldSetText⋯等等。這類前端的類別與方法通常是用來與使用者達到互動。
九、套表
就官方的定義而言，套表是用來顯示動態信息的。既然是顯示動態信息，就表示其中的信息是要讓使用者可以看的到，更深入一點，就是讓使用者可以透過套表來跟資料庫中的資料作互動。所以套表在Notes中真的佔有很重要的地位，而且應用層面甚廣，例如，單純顯示文件中的信息、讓使用者輸入資料以建立文件、編輯文件中的資料以更新信息、在套表事件或是其它組件加入程序以運算處理文件中的資料…等等。在ND6中則可以直接查詢RDB中的資料。ND7開始更可以和DB2資料庫做資料交易。
但是，回到原點，沒有任何其它設計組件存在的空套表是沒有實質意義的。所以當套表中存在field、按鈕、動作按鈕、小節、焦點信息、有程序的事件…等等設計組件，才能發揮出套表的功效。相對於文件是許多item的容器，套表則是許多設計組件的容器。例如在Web上可以在套表中嵌入視界來美化視界在Web上的呈現。
再回到套表最主要的功能－建立與編輯文件。就建立新文件而言，當使用者在各field中輸入數值並儲存以後就會產生一份文件，而field中的數值則會儲存到該文件中的各item中。另一方面，當使用者利用套表開啓已經存在的文件時，套表的field通常就是用來顯示或編輯item的數值。
Top
十、文件
其實在上述中差不多已經把欄位、套表、文件的關係解釋的差不多了。所以在這兒我們就只稍做補充。
由於Item無法自行存在，而是必須存在於文件中，所以換言之，Notes文件可以說是包含一個以上Item的集合，這可說是一個抽象的觀念。其實有些人會認爲視界有顯示出來或是套表可以打開的纔算是文件，但其實不然，因爲文件也有可能是「隱藏」在資料庫中而不顯示的。這就是常有人會看到工作區的資料庫顯示有未閱讀文件，但又在視界中找不到的原因。
另外，也有些人會認爲文件跟套表是一體的，事實上也不然，套表與文件是分開的，就如同先前曾經提到，套表是爲了讓使用者可以新增、編輯、顯示文件的。但也有例外，如果在套表屬性中有勾選文件與套表一起儲存的屬性時，文件與套表就會儲存在一起，但通常不建議如此做。因爲把套表中的所有設計組件與文件合併儲存在一起，就會讓文件的體積變大，進而佔用硬盤空間。就像是本來只有55公斤的Louis穿上幾件衣服後，可能就增加到57公斤了。
另外，在Notes中還有一種特殊文件，就是設計文件，也就是開發者開發出來的設計組件，像是套表、視界…等等，也是以文件型態存在的，這些文件統稱爲Design Notes，不過當然也可以稱爲Design Document。在DominoDesigner的設計組件清單中，使用滑鼠右鍵單擊任一組件，都可以看到該設計組件的文件屬性。順帶一提，在早期Notes文件並不稱爲Document，而是稱爲note，所以纔有Lotus Notes這名字出現。
但是把話說回來，因爲Notes文件的資料並無法像關聯式資料庫可以利用key值把各資料做互相關聯，所以產生一些資料處理上的不便。不過這類問題通常還是可以經由技術上來解決的。而且也因爲如此，Notes才能成爲各種關聯式資料庫的整合接口，不是嗎 ^_^
十一、自我提升
當我寫下這個標題時感覺有點心虛，因爲好像在灌水，呵呵。不過相信接下來Louis所說的，絕對是讓各位初學者非常受用的。
一般剛開始開發NotesAP時，相信大部分使用者提出的需求都是主管去談的，而您絕對是傷透腦筋在想功能寫程序的那個人。雖然這是很一般的程序，但對於您的未來其實不見得是好處。雖然可以寫出一支令使用者滿意的AP絕對是一件很了不起的事，但是當您完成這支AP以後除了學到很多程序技巧與成就感以外，您還獲得了什麼？這是非常值得思考的一件事。
Notes的精髓在於籤核流程的開發，而籤核流程的精髓則是各產業的Domain KnowHow，也就是各產業的專業知識。所以當您接下主管交付的需求後，並非一味的埋頭苦思程序該怎寫、功能該怎開發，更重要的是去了解此係統的真正目的是什麼、流程爲什麼要這麼跑、使用者在籤核底下的作業是什麼。所以您應該再找機會去跟提出需求的使用者瞭解他們的作業程序，進而從他們的腦袋裡學習他們領域的專業知識。
其實，我常常在跟使用者談需求的時候，即使懂也裝不懂，很有禮貌的請使用者重頭講一次，反正被罵笨也無所謂，因爲目的已經達到，大不了晚上抱着枕頭哭一下就好了，隔天又是好漢一條，哈哈。
當您在各產業待過以後，這些知識就會逐月逐年累積成爲您的寶藏。而這些寶藏將會在以後成爲您闖蕩江湖的寶刀。因爲往後當您在與使用者談需求時，由於您的寶藏取之不絕用之不盡，頻頻點頭稱是的將不再是您而會是使用者。
我相信應該很少朋友希望自己永遠靠寫程序維生，尤其到了一定年紀以後，寫程序反而是一種負擔。所以接下來賴以維生的將會是您的Domain KnowHow，幫您賺錢的絕對是您的腦袋與口才，而不是寫程序的技術。這時應該要很高興您不是修計算機的信息人員，而是寫Notes的人員。所以，趁現在趕快累積您未來的財富吧!!加油!! 加油!! Go!! Go!! Go!!
嗯..還沒結尾..請繼續閱讀..感恩Orz
十二、視界
在隨筆（二）中，Louis跟各位討論到文件與套表的關係，所以接下來，我們就來談談視界吧。
視界這個設計組件，很多人都會把它拿來跟RDB（關聯式資料庫）的table作比較。其實是有那麼點像，所以在ND7纔會改良出SQLQuery視界這玩意兒。不過，撇開視界與table的比較，視界的主要功能是爲了有系統的整理資料庫中的一大堆文件，將這些文件中的關鍵信息分門別類的「顯示」出來，好讓使用者可以快速找到他們所需要的信息。所以您要說視界是由一大堆文件所組成也不爲過。但因爲是給使用者使用的，所以在設計一個視界的時候，最好可以先與使用者討論清楚，否則被要求重排視界的可能性非常的大。
不過，若從設計面來看，視界應該說是由直欄所組成，畢竟沒有直欄的視界是沒有任何用處的。在前面，我曾經把「顯示」這兩個字特別標出來的原因是，直欄除了可以直接顯示文件的欄位值以外，您也可以透過直欄公式來處理多個欄位值後再將其顯示出來。也就是說，處理過後的直欄值並非儲存在文件中，而僅供「顯示」。優點在於，您不用在文件中放一大堆計算欄位來儲存一些只爲了「顯示」用的數值。但缺點是，若直欄中有太多的計算公式，則視界的負擔就會加重，因爲它必須要計算每份文件的欄位值。當文件數量很多時，其負擔是可想而知的。
我想大部份的初學朋友都知道「視界選擇」這玩意兒吧，這玩意兒講明白一點就是透過您指定的條件來篩選要顯示在此視界的文件。最不嚴謹的條件當屬【select @all】，因爲它會將資料庫中所有的文件通通顯示在此視界中。最常看到的條件應該是【selectform=”套表名”】，視界會根據您所指定的套表名來搜尋並顯示使用此套表建立的文件。當然您也可以搭配更多的條件設定來更進一步篩選文件，像是某個欄位等於、大於，或小於某個值。
有人可能會發現在「視界選擇」下面有個「套表公式」，Louis曾經遇到一位我覺得還不錯的程序設計師，但他卻從來沒用過「套表公式」。這真的是很重要的功能，但我要在此賣個關子，之後會搭配其它功能來說明。
另外，如果您已經熟悉公式與LotusScript的話，相信您一定常用到@DBLookup、@DBColumn、GetDocumentByKey、GetEntryByKey…等等搜尋類函式與方法。使用這類程序的第一要件當然就是要把視界中的第一直欄設定爲排序。不過，Louis要講的重點不是這個，我要講的是…ㄜ…忘記要講啥了…果然年紀到了就是會這樣..><..（一分鐘後）對了!!我要講的是…當您在設計視界時，請儘量將程序用的視界與使用者用的視界分開，因爲當資料庫中有很多視界時，若您共享這兩種視界又沒特別註明的話，哪天使用者要求您重排視界，結果運氣不好的您移動到程序用視界的第一直欄，那就糗大了，因爲一定會有程序找不到符合的關鍵詞資料，而這很有可能讓您花上大半天去找蟲蟲何在。至於要怎標示，把視界名稱括號起來就好了，要不就在視界屬性的註明欄位註明。不過Louis偏好前者，因爲前者可以把視界隱藏起來，也就是說，當使用者按下【檢視】【移至】也看不到那個視界，除非他們知道按下Ctrl + Shift +【檢視】【移至】（又學一招了吧，呵呵）。
既然剛剛提到GetDocumentByKey與GetEntryByKey這兩個method，就順便提一下這兩者的差別。如果您曾使用偵錯器觀察的話，就會發現前者是傳回文件對象，所以理所當然會把文件中的所有欄位值還有一堆屬性通通抓出來，而後者就只會抓到視界中直欄值。這有什麼影響嗎？當然有影響囉！使用GetDocumentByKey與GetEntryByKey可能還察覺不出來，當您使用GetAllDocumentsByKey與GetAllEntriesByKey來傳回上百筆的資料，相信您就可以察覺到Server Loading的不同了。
十三、資料夾
既然談到視界，就不得不來談資料夾。這裡的資料夾當然不是指Windows的資料夾，Louis要說的是Notes的設計組件之一的那個資料夾。資料夾跟視界非常之像，我們可以說它們是龍鳳胎也不爲過，因爲最明顯的差別在於”視界選擇”。ㄜ..沒有「視界選擇」那怎篩選文件啊！？既然沒有「視界選擇」當然就是有其它的方法可以篩選囉。資料夾篩選文件的方式可以透過程序或使用者手動篩選（複製或剪下，然後貼上）。換句話說，資料夾內的文件主要是由程序或使用者手動置入的。
資料夾應用的最徹底的當屬郵件資料庫了，收件匣各位應該很熟悉吧，它老兄就是資料夾而不是視界，從R5的郵件資料庫可能還看不太出來哪些是資料夾，哪些是視界，但從R6的郵件資料庫就比較容易分辨了，因爲它多了一個「視界」的展開項目，在裡面的全部都是視界。不過在「視界」的展開項目以外還是有視界的。若要真正去辨別的話，還是要從Notes Designer比較明確一點。
先來解釋「手動」放文件到數據夾的觀念吧。假設A視界與B視界的視界選擇條件一樣，其所篩選出來的文件其實都是同一份文件。但是，當您在C資料夾與D資料夾中各看到一份幾乎是一模一樣的文件，在資料庫中它們『可能』不是同一份文件，而是兩份文件，原因在於資料夾是獨立的個體，所以手動個別貼上的話就會是兩份文件。簡單來說，資料夾的文件是被「放」進去的，視界的文件是被「篩選」出來的。這樣您應該就懂了吧，再不懂，那就請您去郵件資料庫多玩幾次複製或剪下，然後到處貼上的遊戲囉。好吧，再雞婆舉例說明一下：
1.當您從A視界中複製一份文件，然後貼到C資料夾，此時C資料夾有一份文件，D資料夾會是空的，A視界則變成兩份文件。
2.再到D資料夾貼上那份文件，這時C資料夾還是隻有一份文件，D資料夾當然也只有一份文件。但是，回過頭來看原來的A視界，您會發現A視界中會變成三份文件。
3.這三份文件=原來的文件＋C資料夾的文件＋D資料夾的文件。其實從文件屬性中可以看到這三份文件的UNID其實是通通不一樣的。
以上都是手動放文件到數據夾的觀念，接下來就是「程序」放文件到數據夾的觀念了，使用NotesDocumentCollection.PutAllInFolder將文件放到數據夾中時，文件並沒有增加，因爲PutAllInFolder並不是「複製->貼上」文件，而是幫助數據夾「篩選」出符合條件的文件再「顯示」出來。所以來源視界與數據庫中的文件是不會增加的。
資料夾有一個很好用的功能－排序。當您使用GetAllDocumentsByKey從視界取得某些文件時（NotesDocumentCollection），這些文件並不會按照原視界的排序一份份排好，所以如果當您的需求是要「依照某種順序」來處理這些文件的話，您可以先建立一個資料夾，並將此資料夾的排序設定成您想要的，再用PutAllInFolder方法把文件通通「顯示」到裏面進去，這樣您的文件就會照順序排了。不過請記得，處理完請務必記得再使用RemoveAllFromFolder把那些文件從資料夾刪除。否則這資料夾中的文件會一直增加，這樣就會造成之後所處理的文件不是當次放進去的文件，而是累積已久雜七雜八的文件。
十四、隨處可得的文件
這一篇是要響應某位匿名朋友的問題－何謂前端文件、後端文件、屏幕上看到的文件、內存中的文件、數據庫中的文件？其實在前面幾篇中，已經有談到文件的觀念，不過沒有以這幾個項目來做區分說明就是了，所以這部份我們就當作再次溫習文件的觀念吧!!再者，路哥認爲這問題以一位初學朋友而言問得實在是很不錯。而這問題我相信也是衆多初學者的問題!!
1.後端文件
後端文件的產生基本上可以分成兩種－透過套表產生與透過程序產生。前者當然是由使用者開啓套表，並在相關字段輸入數據後「儲存」產生的。後者則是透過Lotus Script或Java產生的，例如Set doc = New NotesDocument(NotesDatabase)……Calldoc.Save(True,True)。您看看，這兩者都有「儲存」的程序喔，如果沒有儲存的程序，文件就不會在數據庫中產生。當文件進入到數據庫中時，我們就可以稱它們爲後端文件了。而在Lotus Script中是以NotesDocument類別來實現的。
所以，只要是已經經過儲存的文件，我們就可以統稱爲數據庫中的文件。
2.前端文件
至於前端文件就很簡單了，不管是新文件或是原本就已存在於數據庫中的文件，只要是透過套表呈現到屏幕上的就都叫做前端文件。所以其實屏幕上看到的文件就等於前端文件，其主要的作用在與使用者達到互動。在Lotus Script中則是以NotesUIDocument類別來實現的。
3.後端文件與前端文件的關係
同一份文件會不會同時擁有前端文件跟後端文件呢？答案是「不一定」。
在前面的隨筆中有提過，利用套表開啓一份新文件時（也就是前端文件），打開文件屬性方塊後是看不到什麼較實際的信息的，因爲還沒經過儲存程序，也就是說未儲存的新文件就只有前端文件。
但用套表開啓一份已存在於數據庫中的文件時，在屏幕上看到的就是前端文件，您在上面修修改改尚未儲存的數據均可視爲前端文件的部分。但此時開啓文件屬性方塊，您可以看到此文件的相關屬性與各字段數據，這部份則是屬於已儲存之後端文件的部份。若您在此時按下儲存，前端文件的數據就會更新到後端文件中了。這就是前端文件與後端文件並存狀況。
至於在Lotus Script中怎麼透過前端文件來取得後端文件呢？只要使用NotesUIDocument.Document即可，因爲NotesUIDocument代表目前開啓的前端文件，而Document則是指目前文件的後端文件。
4.內存中的文件
這部份麻，我想就跟Lotus Script或Java程序設計有關了，我儘量解釋您就儘量看看，能吸收多少算多少。
在LotusScript中有NotesDocument與NotesDocumentsCollection的物件。當您使用GetDocumentByKey方法取得NotesDocument對象，或是使用GetAllDocumentsByKey取得NotesDocumentsCollection的對象時，被取得之文件對象所包含的所有數據都會被儲存在內存中，等待您進一步的處理。
在前面路哥也提到過，若文件中有很多數據，則太多的文件就會造成內存的負擔，所以，如果您只是很單純的處理少數資料，就請儘量使用NotesViewEntry或NotesViewEntries，因爲內存只會儲存文件在此視界的直欄數據，而不會儲存文件的所有數據。
5.結論
文件是很抽象的觀念，我稍微將它具體化一下，但並非一模一樣。數據庫就類似公文櫃，視界就有點像是公文夾，文件類似現實生活中的公文。如果沒有公文夾視界來將文件分門別類的保存起來，數據庫就會像是一個擺放了一大堆雜亂無章文件的公文櫃。
我建議您可以再回到前面幾篇溫習一下，相信會有不同的感覺的。
十五、選擇開啓文件的套表
回到咱們的進度上吧，在本篇隨筆中，這一節算是唯一在進度上的一節。路哥好像沒有談到有進度吧，因爲進度在路哥的腦袋瓜子裏，呵呵。
相信各位在看過前三篇隨筆後，對文件跟套表的關係應該有一定程度的瞭解，所以接下來要爲各位介紹的是，當您開啓一份文件時Notes是如何決定要用哪一張套表來顯示文件。
不懂路哥在說什麼嗎？沒關係，我就再稍微解釋一下，Notes文件並非只能使用當初建立此文件的套表來開啓，也就是說一份文件可以使用不同的套表來開啓，而產生的結果就是在前端呈現的文件之排版與數據會不同。例如，有A與B兩張套表，A套表有兩個字段－AAA、BBB；B套表只有BBB字段。另外在數據庫中有一份文件儲存了AAA字段值111與BBB字段值222。這時使用A套表開啓甲文件時，您會看到屏幕上顯示111與222兩個字段值。接下來再用B套表開啓甲文件，此時您就只會看到222而已。也就是說同一份文件會因爲套表上的排版與字段不同而有不同的顯示。
用最最最簡單的實際例子來說明好了，假設路哥有兩條牛仔褲，A牛仔褲的左邊褲管剪了一個洞，而B牛仔褲則是在右邊褲管剪了一個洞，當路哥穿A牛仔褲時就會露出左膝蓋，穿B牛仔褲時則是露出右膝蓋。即使你們會因爲我穿不同的牛仔褲而看到不同的膝蓋，但其實路哥本身還是有兩個膝蓋，並不會因爲穿哪件牛仔褲而真的少了哪個膝蓋。不過……路媽要是看到我穿這種牛仔褲，一定又會念說，你是沒錢可以買褲子喔!! ><
好回到正題，Notes是如何決定要用哪張套表來開啓文件的。採用順序爲，套表與文件合併儲存à視界的套表公式à Form字段值à數據庫的預設套表。說明如下：
1.套表與文件合併儲存：這在隨筆2中的第3頁的倒數第三段有解說過，請自行回頭參考。
2.視界的套表公式：這個就要特別解釋了，因爲曾經有兩位從軟件公司出身的朋友同時問過我一個問題就是，如何在視界中依不同的條件來選擇不同套表開啓文件。其實滿驚訝的，因爲我覺得這是非常基礎的功能，而且是必須知道的。所以在此特別說明，答案是視界的套表公式，在哪兒呢？就在寫視界選擇公式下面的那個「套表公式」。
簡單來說，您可以寫一行程序，假設A字段值=1時就用A套表開啓，否則就用B套表開啓。所以當A字段值有所變動時就會使用不同的套表來開啓文件。個人覺得這功能雖然很少用，但是，卻是很好用的功能。
3.Form字段值：在Notes中有個保留字段叫做Form，而此字段值就是在儲存用來開啓文件之套表的名稱，所以強烈建議使用Lotus Script建立新文件時都要指定此字段值（語法：doc.Form=”套表名稱”）。
4.數據庫的預設套表：在套表的設計屬性的基礎卷標下有一個「預設的數據庫套表」選項，若勾選此選項後，前面所說的條件若都不成立時，就會採用勾選此選項的套表來開啓文件。我想應該會有朋友問說，那要是有兩張套表都有勾怎辦？那您就勾勾看吧，呵呵。一個數據庫只能存在一張預設套表，所以後勾的贏，也就是說若A套表勾了以後，B套表又勾，那系統就會自動取消A套表的該選項。
好，講到這邊整理一下，當您開啓一份文件時，Notes會先參照文件當初儲存時的那張套表是否有勾選「套表與文件合併儲存」屬性，若有則採用該套表開啓。若沒有就會參照視界的套表公式，所以若您有寫套表公式時就會依照該公式的條件來開啓文件。若沒有寫套表公式，那就會參照文件中的Form字段值，若文件中此字段值有指定套表名稱，就會使用該套表來開啓。若沒有則會參照最後的防線－「數據庫的預設套表」。若數據庫中沒有預設套表呢？如果路哥沒有記錯，系統好像會出現「找不到套表」之類的錯誤訊息。不過也有可能記錯喔，最近腦筋不太靈光…呵呵。
十六、Lotus Script超基礎觀念
這是路哥突發奇想的主題，相信初學者的您在看完此節以後，一定會非常有收穫唷!!
LotusScript是以對象爲基礎的程序語言，還談不上是完全對象導向的語言。市面上有很多書籍在談對象導向，好像一開始都是用車子或飛機來當例子，可是路哥總覺得缺少了什麼。所以長久以來路哥一直很想找出某種生活上的實際情形來與LotusScript中的類別對象相對照，讓初學者有很清楚的概念。在某天明月高掛的夜晚，終於讓路哥頓悟了，就只差沒成仙而已。因爲是新的想法，所以各位這次就當作是路哥的白老鼠吧，感恩不盡，若有講錯的地方還多多海函 Orz。
在開始之前，路哥先聲明不把所有的類別都拿出來講，我只用了幾個比較常用的類別，其餘的就交給各位自行體會了。讓我們開始吧!!
Lotus Script的特點之一，就是有很明確的對象階層，而且大部份每一階層對象皆會包含下一階層對象（NotesItem是最底層對象，所以只有方法與屬性）。
例如NotesSessionà NotesDatabaseà NotesViewàNotesDocumentà NotesItem。
精采的來了，我的虛擬實景是：
1.NotesSession = 地球，因爲地球是一個大環境，包容各式各樣的對象與數據。
2.NotesDatabase = 臺灣，因爲每個國家就像是一個數據庫，有很多的文件跟視界存在。
3.NotesView = 縣市行政區，每個縣市可以視爲一個view都是以現式的名稱來將位於各地的房子篩選出來，所以NotesDocument=房子，如下說明。
4.NotesDocument = 房子，因爲房子有很多數據，像是地址就可以比做是UNID，因爲地址絕對不會重複。
5.NotesItem = 房子的基本數據，透過GetFirstItem就可以得到類似房子有幾坪、戶口數、在第幾層…等等的信息。
所以呢，現在如果我們想要知道路哥房子的房間數，程序可以這樣寫：
Dim 地球 As New NotesSession
Dim 臺灣 As NotesDatabase
Dim 臺北縣 As NotesView
Dim 路哥的房子 As NotesDocument
Dim 房間數 As NotesItem
Set 臺灣 = 地球.CurrentDatabase
‘ 因爲我們現在在臺灣，所以就用CurrentDatabase
Set 臺北縣 = 臺灣.GetView(“臺北縣”)
‘ 假設臺北縣這個View是以戶長姓名爲第一直欄而且有排序
Set 路哥的房子 = 臺北縣.GetDocumentByKey(“路哥”)
‘ 既然是要找路哥的房子，當然Key值就是”路哥”囉
Set 房間數 = 路哥的房子.GetItem(“房間數”)
‘ 因爲要查路哥房子的房間數，所以就直接去找房間數這個字段，此時傳回值會
是3，因爲路哥的房子是三房兩廳。
舉一反三，如果要找路爸的房子呢（不是路霸喔，是路哥的老爹啦…哈哈），那就把Key值改成”路爸”，因爲路爸也住臺北縣囉，這樣就可以找到路爸的房子數據了。
如何，夠清楚吧，爲什麼路哥會想用這種方式解釋，是因爲這樣比較能夠感覺出Notes是文件式數據庫的感覺，至於市面上那些使用飛機、車子當作例子的書籍，我想作者們應該是爲了表達對象導向的觀念吧。
