修編族譜是一個繁雜冗長的過程，不是二十世紀的大學聯考，千萬不用急。到冰箱找點啤酒，喝玩半打後，再回來想想如何修，然後花上二十年的時間慢慢玩!

雖然從家譜的原稿墨跡，可以了解家族歷史一二，但我很懷疑我了解當年墨汁硯台背後的使用技術。不要說百年的資料，十年前的電腦科技與今天的使用概念可能毫不相干。這個網頁也必然在很短的時間內成為落後科技。

我也不知道老人家我明天搭飛機會不會摔扁... (滑翔機其實相當安全)

因此，我想以此篇文章來解釋族譜網頁及資料結構庫的技術背景。

歷史資料背景

• 維中於 2001 四月間將原版手抄本轉成數位資料(轉換過程有打錯的可能性)
• 2001 七月間將數位資料轉換為資料庫檔案(轉換有錯誤的可能性)
• 其他歷史背景請參閱"序"

文字背景及推薦

• 族譜中有許多稱呼，可能失考
• 許多稱呼，在不同年代，意義並不統一 (注意"繼"與"室"之分)
• 對於來世世孫，不論男女，不僅生辰猝日等，務必詳載其生。僅知道曾曾曾曾曾祖父名為啥，實在無聊!
• 從前先祖可能忌諱病因或是死因等紀錄。對於來世世孫健康而言，特別是遺傳性疾病，此點有莫大正面作用。如可能的話，務必詳細記載。
• 有許多的字，今已失傳或是無法翻譯，需保存原始資料。
• 此版家譜，失傳或是無法翻譯的字皆列為"★"。
• 原始資料無法解釋同父異母的狀況。
• 老實說，我有相當多的背景需要了解。待老人家我有更多時間後，我會繼續充實這個部分。

網頁技術背景

老人家我教了四年研究所的"資料結構庫概論"，所以好像你會有個很好的設計... 

第一點，家譜是一個非平衡的樹枝架構。技術上除世祖外，每個人都有父母，但多少個配偶與孩子不定，並且同父異母的可能性頗大。在 1970 年以前，市面上真有商用 Hierarchy 資料結構庫，處理如此問題效率頗佳。今天 2001 年，Hierarchy 老掉牙不講，你也買不到一般消費者可負擔的產品。

取而代之的是 Relational 資料結構庫，也是目前(2001年)較為普遍的消費產品。基於網站伺服器，未來相容性，以及簡單經濟等。我所選擇的資料結構庫為微軟的 Access (DSN with ODBC) 及 SQL Server 7.0 產品(好玩起見，我用了兩組應用，看看誰真的跑的快)。如未來二十年內，世孫有意重修此資料結構庫，請參照下列物件導向資料庫 Object Oriented Database 與 Relational 間的建議。

基於方便以及使用性，這個資料庫並沒有完全 Normalize。設計概念類似於資料架構的 Link List 和程式設計中大量使用 Recursive 循環搜尋。網站使用微軟的 Windows 2000 伺服器，IIS 伺服，以及 ASP 和 JavaScript 伺服間的應用語言。

由於 Recursive 循環搜尋多少有效率上的考量，加上資料結構庫為 Relational 與 SQL 相容，我決定用資料伺服器來作比較重的工作。這點，也為設計時的考量。但由於非平衡的樹枝架構，時有過量的資料需要處理，就算伺服機有辦法解決，瀏覽器會出問題。之所以如此，在 [細節] 瀏覽時，目前設定為五世之內的搜尋。

資料結構庫

目前時間有限，我會將詳細資料，物件導向資料庫 OODB 轉 Relational，程式詳解釋，及下載資訊，在近期內做好。