以下主要是簡單介紹平台所使用的核心靈魂模組,
而程式對應的Header檔中皆有相當的函式對應說明,
所以這裡只針對來由想法而不作深入,
但建議有時間可先看過一次對應的Header函式說明,可以先有個整體性概念易於理解

1. Queue:
W_StringFIFO_List
程式碼位於
net\W_StrLst.cpp

如同.Net/C#之設計開發人員,都會注意到微軟所推的MSMQ,
在稍微有複雜度的程式開發上,Queue的運用可以讓程式開發相對比較容易,
模組W_StringFIFO_List 與MSMQ最大的差別在於與作業系統無關,
而Queue的最大功能共通點是 Store and forward的功能,
雖然 Store and forward這個學術名辭通常都是在網路通訊中被使用,
但實質上它就是Queue的功能最佳的主要解釋,
而一個網路設備中的軟韌體性能優略也完全取決於Queue的設計是否良好,
Queue的另一個特色是有序,
模組名稱中 FIFO 指的便是 First-In/First-Out, 也就是先進先出的概念,
特別是 W_StringFIFO_List 於Windows環境下已設計成為是Multi-Thread Safe的模組,應用上非常方便

2. Data:
W_DataLink
程式碼位於
net\DataBase\W_DatLnk.cpp

任何程式開發都會有或多或少的資料要處理,最普遍直接的用法通常是使用Array不然就是Data-Link,
Array的好處是容易建立起可排序和搜尋的資料集,
而Data-Link的好處是增刪資料只須變更Link而不須影響存在的資料,
目前平台中皆以Data-Link的方式作為資料儲存的最主要方式

3. Table:
W_DataTable
程式碼位於
net\DataBase\W_DatTab.cpp

承2.平台雖以Data-Link的方式作為資料儲存的最主要方式,
但卻利用Table的概念使用Array的方式來快速排序和搜尋Data-Link中的資料集,
而Table所使用的Array往往比結構資料直接形成Array的方式要來得小很多,
因此在大結構的資料處理中,不論是資料搜尋排序或是新增刪除皆能以非常高之效率來完成,
而若是小結構與大數量的資料處理,效能雖然可能略遜,但程式穩定的設計卻是相對容易,
再如果是小結構與小數量的資料處理,我想效能已不會是被注意的項目了!

4. 資料表:
W_EzSingleTable
程式碼與 W_DataTable 同樣位於
net\DataBase\W_DatTab.cpp

資料表其實就是 Data + Table ,
使用資料表在程式中作資料處理是非常輕鬆的事,
只要決定好資料的搜尋和排序要用的key,
再來就是隨時的新增與刪除資料(排序自動進行),
也能隨時於資料集中快速搜尋到要找的資料了!

5. 動態資料表:
W_DynamicTable
程式碼位於
net\DataBase\W_DyTabl.cpp

這個動態資料表相當於 Data + Table(s) ,
其實是上面 W_DataLink 與 W_DataTable 的前身,
由於觀念翻新才將 W_DataLink 與 W_DataTable 獨立抽出,
並將此動態資料表改由 W_DataLink 與 W_DataTable 所組成,
它的概念是在於同一個資料集用多個不同key的Table同時處理,
例如結構中有中文名稱和英文名稱,
用它設計就能隨時以英文或中文查出結構所在
而用法就跟 W_EzSingleTable 一樣簡單,
而建立 W_EzSingleTable 的原因也是因為單一key的使用方式較普遍,
所以用來簡化使用 W_DynamicTable 只有要設計一種key時取而代之用

PS. 除5.這個舊的模組之外,
1~4的模組程式皆相容於Linux/Unix作業系統,只要有KGQ就表示已存在這些模組

6. 關於雲端
針對雲端,核心觀念是Map/Reduce,
最簡單的就是像 5. 這樣的動態資料表,
一個資料集,使用多個Table可進行不同key之管理方式,
而不是傳統做法,建立多個Index與資料的Array相對應,
因此相同欄位的資料不需要在程式中存放兩份,可以作到資料精簡單一

更深入的做法則不只是用多個表來處理單一資料集,
而是使用資料表再去對應一個甚至多個資料表,
而這個用來對應的資料表,其結構可能是一堆address
包括key是一個key function address指向被對應的資料表中的對應key資料的位置
包括一些方法,也就是函式處理的 process function address,
或是類似關連性資料庫的概念,將多個不同資料集的資料表,
透過此對應用資料表來建立關聯,它也可以去對應檔案/網路,對應一堆複雜的處理模組等,
因此使用一個相對小的對應用資料表可以管理TB等級的資料處理,
也就是雲端等級的資料處理系統,
當然更進一步可以是一堆對應用資料表又透過一個對應資料表來對應管理,
想起來既簡單也複雜,應用執行面則相對單純,
所以台灣目前也只有雲端應用而無任何技術上的開發,談雲端都是天價的成本投入,
但如果由技術面逐步開發投入,可以節省的成本與產生的效益也是相對可觀!