由上星期開始﹐我的生命好像進入了黑暗時期﹐好像回到以前六月飛霜的時代﹐雖然那時都是黑暗時期﹐但當時還會有人懂得用 SQL 起 Table﹐每個同事都有獨立解決問題的能力﹐大家只有唔願做﹐沒有唔懂做。

現在盟友只懂用 Management Console 起 Table﹐ SQL Query Builder 和 Google 是他的好朋友﹐「可唔可以過來幫下手」是他的名言。

寫 JOIN 超過兩個 Table 的 SQL 太複雜﹐要理解 View 和 Store Procedure 更加是無可能﹐﹐盟友悟出報表裏每個 Sub-Group 都起一個 Table 來儲數據來避免複雜的 SQL Statement 這個大智慧引致數據庫的 Table 數量迅速增加。理論上以上情況﹐每個 Table 的結構都應該一樣﹐可惜吾太天真﹐真實情況是只有一個 Table 有 Primary Key﹐餘下的都沒有。

吾問大師為何﹐他說用後覺得沒有需要。可能真的沒有需要（這麼多 Table）﹐但為何同一類 Table 的 Key Field 一邊是 nchar 一邊是 int 呢？他回答為手誤之固。神呀！我真的被雷倒了！他這樣才是玩數據庫﹐這樣的情況他的程式竟能安然無事﹐而我只是被玩呢！難以想像日後這些 table 有超過一萬隻數據之後報表要何年何月才能印出來﹐畢竟這可是每天都在印呀！

過了一天後終於真相大白﹐原來 identity 對他來說如魔物﹐每次加入紀錄都會自動增加﹐盟友認為其刪除數據後再新增﹐數字未能順序不美觀而且影響排序。吾送贈 DBCC CHECKIDENT(XXX, RESEED, 0) 指令一個之後﹐他「託」吾幫將之前建立的 Table 的 Key Field 變回 identity﹐這就是吾能探究大智慧之底因。

吾以往已和大師一同經歷過帶一個完全不能運作的程式去 Deployment﹐引致原本 Training 變成狂改程式至深夜（佢在旁監督我改﹐但程序是他寫的﹐原意是要我去輔助佢 Training）﹐無車回家的慘況﹐其實心裏也有個底﹐只是未能理解大師的能力之低﹐做事之求其竟能超越吾之所想。

吾身為一介蟻民﹐只可以盡量避免接觸大智慧﹐生活在自己小小的安全領域之上﹐地球上危險的事太多﹐吾只紀錄了有關數據庫方面的事情﹐如果進入程式碼之世界﹐大家會發現更多竼音﹐例如 aaaa,, bbb, ccc, e 等變數﹐ _xxx 等檔案名稱﹐大智慧告許我們 _ 字頭的檔案一般排得更前。吾只能說：「It is Shit!」

P.S. 今天又新增怪事一則﹐盟友之程式在測試階段未能運作﹐後來發現因為測試機的作業系統是中文﹐所有插入之日期數據全部爆廠﹐因此再次提醒各位施主﹐以字串把日期數據插入只能在開發機順利運行。