由 database 設計主導管理

我見證過某啲 IT project 目的在於提升管理水平,但系統好多時都過於覆雜難以運用,效果比預期差得多,甚至令管理方式更加受制於電腦系統而變得僵化。客戶普遍嘅技術知識相當有限,缺乏改良系統嘅能力係理所當然,但最常見嘅問題係連基本嘅 maintance 都有問題。另一方面,IT 界嘅工程師普遍對人嘅溝通能力有限,只會根据客戶嘅 requirement 主導,甚至受客戶嘅腰求不断改變而更改設計,好多時淪為覆雜同另類嘅設計以滿足客戶腰求都唔主動提出專業意見,唔少難尾收場,就算能夠完成都並非客戶所想像一般易用或者穏定。

我只限於寫簡單嘅 web application,曾經寫過一個圖書館借書系統嘅習作,有借書還書續借功能同介面,簡單用 Microsoft Access 嘅 mdb file 造 database。我認為系統嘅重點在於 database 設計,點図妥善整理好啲 record 儲存又容易揾番去黎同修改,相對 work flow 只不過係一個不断改變嘅 status value,同金額一樣唔係系統設計嘅重點,亦唔適合用電腦系統限制管理手法嘅彈性,限制解決問題嘅可能性。

book status flow chart of library system concept

Microsoft Excel 或者 Google Sheet 主要功能在於算式功能,但有 DB 一樣嘅 column 同 row,對応 DB 儲存 data 嘅格式。但如果要入好大量 data,Access 先係真正相當於 DB 嘅軟件,更適合用黎入資料。當中最重要嘅功能係 table relationship 功能方便設計 DB,點図拆開嘅 data 到唔同 table 儲存,然後加上 unique ID 防止重復同提升搜尋效率,資料之間嘅關係同邏輯應該係管理層要理解嘅事項,可以想像輸入表格裏面 dropdown list 嘅每一個選項背後係黎自一個 table,一個 form 就可能由好多個 table 嘅資訊組成。管理層最基本應該有 DB 設計嘅能力,將所有資料整理到 mdb 裏面,經過長時間運作同俢改之後,如果想更加方便同加入權限或者 data validation 之類功能令輸入資訊更準確,UI 介面可以外判到有寫 code 能力嘅 IT 界逐張逐張加,根本唔需要為所有 table 制作 UI 介面,最終離唔開要直接用 DB 嘅 UI 修改小量 data。

table relationships in Access

UI 點図造 user friendly 背後有一定 technical constrain,唔係畫得出黎就造倒,應該由 IT 設計。客戶最重要係提供一個有小量 sample data 嘅 mdb file,裏面有已經落實嘅 DB 設計係最好嘅溝通媒介,只能夠靠有權接觸所有 data 嘅管理層設計出黎。大致上要理解 table 裏面嘅 row 係預不斷增加,但 column 係固定連茖都唔應該改,視苻點設計就有幾多彈性預日後擴充加 column 或者加 table 再加以整合。缺乏系統思維係度至管理水平低落嘅主因,要提升管理效率,離唔要開對細節或者放棄唔重要嘅事項。只有透過 DB設計先會了解到管理嘅復雜性,IT界要係制作電腦系統同介面,最多只可以對設計提出优化建議,並非直接提升管理水平;客戶好多時真正需要嘅係基本關於設計方面嘅教育。

規模細一定比規模大容易管理,相當於產品設計概念有可以要大幅修改先能夠大量生產。因為一般 DB 都屬於 RDBMS, 裏面啲資料有好多 relationship 避免重復所以要一隻過,如果去到公共圖書舘嘅規模,就需要加入另一類 noSQL 嘅 DB 方便不断擴充,適合放獨立又大量嘅 data 例如 book detail 或者 history record,再直接輸出 json 以提升搜尋效率,適合以 API 形式提供查詢介面,例如 ISBNdb API

對於公共圖書館黎講,我認為提升藏書質素同容易搜尋係最重要,例如一頁開放比公眾嘅 “藏書建議” 網頁應該係重點。我認為在管理嘅角度應該傾向有眼光有建設性嘅小数建議,藏書建議 form 上只需要有 ISBN 同原因両欄就足夠,因為有能力嘅人傾向避免書名重復形成誤解,希望以單一嘅 ID 表達,憑 ISBN 喺 noSQL DB 就可以得到 book detail,有 ID 就唔需要其他 field 變得更簡洁。藏書建議 form 最好放喺 OAuth login 之後避免 spam 嘅問題,建議就會連帶 user ID 放到 RDBMS 連接管理系統,集中整理建議。

我認為 RDBMS 嘅 DB 設計先係核心,相當於管理嘅規劃以嚴緊嘅系統提升 data 嘅準確性,裏面嘅 category 分類應該傾向概括同單層配單一嘅 ID,影響到圖書館藏書嘅攞放,盡量避免修改但唔代表僵化,好多時問題出於分類過細或者誤導反倒變得難以搜尋。相對 tag 嘅概念係一串 keywords 嘅 array 比較寬鬆,想容易啲搜尋於是獨立跟每本書放喺 noSQL DB。category 同 tag 嘅混用,同 RDBMS 同 noSQL DB 嘅混用都有互補長短嘅特質,點図取捨達至最適合嘅效果取決於管理水平。

Reference: