你知道早幾年Yahoo!和這幾年的Google都在搞網路搜尋這種技術，兩者之間最大的差異在哪裡嗎？Yahoo!是以「目錄」服務為主，而Google是以關鍵字搜尋為主。所謂目錄，就像以前每年都會主動送到你家樓梯間疊成一落的中華電信電話簿一樣，別去看比較厚的個人用戶那本，翻翻另外一本比較薄的，就可以依照生活水電各種行業的分類來找到你家隔壁巷子的洗衣店，或是轉角那邊的水電行的電話地址等等。這種目錄依照不同的分類法則，來將各個資訊條目分門別類地歸檔、整理。要使用時只要依照目的來找，通常可以很快速地得到想要的資訊。例如肚子餓了就可以去找生活→小吃，電視機壞了可以去找家電→電視，貓咪拉稀可以去找醫院→寵物。關鍵字搜尋就比較有趣了，肚子餓了想吃麵，就可以用關鍵字 "台北", "麵店" 甚至包括你家地址 "XX路" 來尋找最接近的麵店網站，想要修電視，可以用關鍵字 "電視機", "維修", "台北", "XX路" 找到離你家最近的電視機維修站，同理，貓咪拉稀也可以用關鍵字 "貓", "排泄", "生病" 找到有參考價值的相關資訊，甚至不用上醫院就可能知道原因所在和該當如何處置。

你知道法國料理和自助餐兩者的最大不同在哪嗎？法國料理有多道餐序，前菜開胃正餐點心一道道盤子依照順序送上來，刀叉從外側一路撿到最內側，可以選擇的範圍只在蝸牛和燻魚之間，自由度不大但各道餐點間經過精心安排不會有口味衝突的問題。自助餐則依照個人口味喜好隨意點選，坐下來想先來杯冰淇淋也不成問題，主人去付帳準備走了又跑去切塊牛排來湯汁淋漓地切啃也行，愛怎麼吃就怎麼吃。

你知道大約十年前的計算機概論電腦課程中講述的循序儲存和隨機儲存有什麼差別嗎？循序儲存的每個資料單位（Row、Record）必須事先定義好位元長度，然後依序放置在磁碟的空間內，一筆接著一筆記錄，不管該記錄位元是否有填上資料或是代表空值的Null，總之預先排好空間等到要填入數值資料時就可以快速地存取。隨機儲存則容許在磁碟檔案中依照資料記錄內容放置不定長度的記錄單元，有多長就塞多長，整體儲存檔案的大小可以有效降低，如果有某筆記錄需要更動長度就將之搬移到檔案最後，剩下的空缺要不就不使用要不就留待其他記錄剛好可以填補時塞進去。循序儲存的檔案空間比較浪費但索引比較簡單，存取時間比較快，反之隨機儲存節省了儲存檔案大小，但索引相對複雜，存取時間也稍慢。

你知道公司組織上有分部門和專案兩種任務編組嗎？傳統觀念中公司的每個單位都有負責的管理人員，旗下依照樹狀分枝可以納入多名工作人員，或有再下層的部門單位。譬如某公司可以有多個事業處，各事業處可能有不同部門，各部門有不同課室，各課室有不同組。從最上面的總經理（總裁）一直到最下面的清潔人員（阿姨），層層排列，結構清晰。另外也可以按照任務需求，建立專案組織並邀集各種專案從業人員，給予各人員不同的任務角色，團隊合作完成專案目標。從專案經理、風險辨識小組成員、各工作項目人力，不管是負責清理專案辦公室的阿嫂或是偶爾來專案會議室荒腔走板高談闊論的上級指導長官，都可以名列在專案計畫書中，或成或敗地參與整個專案組織的運作。

上面講了多個實際範例，就是要讓你了解在各種的應用途都有可能會聽到這種分類和標籤的差異概念。回到主題，在Web 2.0的口號時代，你會不時聽到標籤（Label）這個名詞從扶著眼鏡的專家嘴巴裡冒出來，所謂標籤究竟是什麼東西？有什麼好處和缺點？如何在系統和資料庫中實作呢？

你在我的網站畫面左側看到的文章分類選項，就是傳統的分類目錄結構。各篇文章撰寫完畢後依據其內容屬性，指定存放在某個分類底下。有的分類在講塔客的心情，有的分類在講大毛的生活記錄，有的分類在講塔客閱聽心得，有的分類在讓塔客發發牢騷四處幹譙。讀者如果對某個分類產生興趣，就可以點擊進入某分類，看看該分類底下的存放文章，或再點擊進入分類底下的「子分類」，一層層深入細分，很系統化地了解整個網站內容的分類走勢。

這種網站分類雖然結構清晰，也很容易讓管理人員掌握整體網站的內容分佈，但對於訪客而言很難在短時間內了解到各分類的管理原則。要找一篇塔客帶大毛去吃火鍋的文章，究竟該先察看塔客的美食報導，或是去看大毛生活記錄分類呢？如果訪客只願意花平均十五分鐘時間在一個網站內瀏覽，通常僅會按照興趣優先分層點閱一到兩個分類，然後就可能結束拜訪轉檯離開。所以用分類來擺放文章，對於訪客而言可以集中焦點觀看某主題相關文章，但容易流於失去主動地位而引致無法認同該網站的氛圍主張。

管理網站不同的方法是標籤，內容提供者依照他自身對於該資訊的認知給予內容 一個或數個的關鍵字註腳。譬如塔客帶大毛去吃東門涮羊肉，就可以加上 "塔客", "大毛", "涮羊肉", "東門", "火鍋", "美食", "相簿", "耍寶", "吵鬧"... 各種的標籤，等到日後要尋找有沒有塔客耍寶和大毛吵鬧的文章時，就可以依照關鍵字搜尋的原理找出這篇網誌文章。標籤的好處在於文章不需要被硬性規定在某個分類框架內，可以依照文章內容的重點，隨時創造新的標籤。缺點是，如果訪客也不知道該當看什麼關鍵標籤，又或著網站內容貧乏每次輸入標籤都找不到符合的文章，就會讓訪客不知所云產生厭惡。

我的網站系統目前採用的分類結構，係利用資料庫內表格記錄各分類的名稱、代碼、上層分類代碼、管理屬性等等，然後存放文章的資料表格內各篇文章有欄位指定所屬分類，等到網站要顯示某分類時，先在分類資料表中搜尋「上層分類代碼」是該分類的子分類列表，再在文章資料表中搜尋分類欄位是該分類的所有文章，便可以將指定的分類底下所有相關資訊一次性表列出來。

若然改用標籤的記錄結構，可以另外準備兩個資料表格，一個記錄標籤本身包括標籤隱性代碼和標籤名稱，一個記錄標籤與文章的多對多關係。每次有文章填寫標籤時，先搜尋標籤記錄表是否已經有存在同樣的標籤，如果是則在標籤關係表中添一筆文章與標籤的記錄，如果標籤不存在就新增一個標籤記錄然後再新增文章與標籤關係記錄。過濾與搜尋標籤以取得文章時，則反向利用標籤文章關係表找到文章代碼，然後表列文章標題。

如果打算提供「關連標籤」的功能，可另外準備一個關連標籤多對多表格，每次新增文章的多個標籤時，就在表格中新建或遞增兩兩標籤的關係記錄計數，反之移除某個文章標籤時則亦須刪除或遞減兩兩標籤的關係記錄計數。如此當顯示某文章時，就可以依照文章標籤列表，然後尋找每一標籤的關係記錄計數最高的其他標籤，讓使用者能循跡延伸閱讀。

好，上面這種網站技術和資料庫結構技術你看不懂沒關係，我只是寫來炫耀告訴一些搞技術的朋友說，你看你看我雖然只是個產品經理，但是我也懂得這些細部技術。這樣就夠了。

有人質疑，難道分類和標籤兩種搜尋內容的方法不能並存嗎？其實是可以的。分類有使用上的限囿但有其管理上的優勢，標籤龐雜的記錄會造成資料庫空間的浪費但又有其搜尋使用方便之處。合併分類和標籤兩種內容管理的方法並不會造成記錄或邏輯上的衝突，卻可以互補兩種方法各自在管理和搜尋使用的優勢。

同理講到今天這篇文章的真正主題，每個人每天的生活，都可以被分類到各個組織，包括坐公車排隊在第幾路站牌，公司搭電梯停在單雙數樓層等等，但也同時可以被標籤藍綠橘黃紅等不同的政治色彩。

因此，各位朋友們，不要管你家地址郵遞區號是多少，也別管你的職業別是士農工商軍警賊匪，只要你願意，你都可以替自己別上一個最偉大最值得驕傲的標籤，「阿扁下台」！

... 各位看到這裡是不是有感覺到被我騙的意味，哈哈哈，這正是我的用意。難得看到塔客寫大部頭的有料文章，還是被你們賺到了。