今日朋友找
我去做了一個一日的打字打工仔
時薪200，八小，現賺1600
工作就是把一份一份的報名表
輸入進去他們的系統
到了那邊
她們拿出了看起來五年有的Dell筆電
一台厚厚的
系統是win7企業版
看到這個我想大概是多數公司擁有的情況
能用就不會換
我就猜可能系統也很舊
果不其然
打開他們的資料庫系統
也是相當的陽春
輸入過程中發現了很多錯誤
由於報名表是手寫的，甚至有其他工讀生處理過的
ID會有寫錯的情況，比如8其實是4
順序錯誤的情況，比如0204結果是0420
諸如此類的錯誤
甚至是字太醜，姓黃的人被寫作姓葉
填報名表的人本身也不細心，寫錯別人的ID之類的
利用了手機號碼去系統尋找帳號資料回推正確ID
那如果沒有ID，手機也錯或是不是申請帳號所填的手機，直接就炸開了
聽聞此活動每年都上演著混亂的戲碼
不禁體會到資料庫設計的重要性
體會1，應建立錯誤修改機制來減少工讀生出錯的可能性：
背後建立一套算法，來自動的做這件事，基本上假設帳戶資料是對的，利用這個當reference table進行自動比對，用電話或是ID進行姓名的對照配對，進而進行update的修改，感覺就是可行的，只是不知道是寫這個快還是人工檢驗快就是了XD
畢竟我覺得我檢查的頗快速= =
以姓黃姓葉的錯誤來說，貌似還要進行字的相似性檢驗，看是真的寫錯，還是是別人的名字
說不定有人拿自己家人的卡做報名，並非本人使用這張卡，這種情形又要不要給過?
似乎還有其他問題要思考
體會2，儲存資料的設計：
有人英文名字都亂填，last name first name搞不清楚哪個是姓哪個是名
造成資料比對的不便
有沒有可能做網路表單進行填寫，自動的輸好輸滿，不需要工讀生?
又想到，如果長輩不知道怎麼使用網路不會使用線上填寫似乎還是要用手寫的報名方式
這部分可能就看怎麼設計了
不然直接像買演唱會門票一樣，點一點那些位子就是誰的，快速許多
體會3，操作系統的介面以及防呆：
一張卡同時可以有兩個人用，但是只有某一個人用這張卡報名的時候，卻只能選擇卡片擁有人，但出席的是副的那個就不能選，於是只好當作是卡片正擁有人報名參加，到時候可能用ID搜尋吧
雖然還是能報到成功，畢竟ID是唯一的，可是就不正確阿，直接能顯示真正來參加的那個人不是很好嗎
防呆跳出的額外視窗(選ok/cancel)不能用鍵盤操控
一直滑鼠點阿點的，感覺一手滑鼠一手鍵盤能快上許多
尤其網路又慢還是系統太廢的關係，跳防呆視窗還要等個幾秒，又不只一個，轉換過程中輸一筆算浪費個5秒
然後一人一天輸入幾百筆，直接浪費個3000秒，每個工讀生總合起來浪費個幾小時，也不是開玩笑的
然而最後的體悟如下：
key資料進系統這件事，他們花的成本大概是10000左右吧，對比起這個活動的營收，這一萬有夠小
這麼一想又覺得，他們確實不必浪費時間開發呢XD
難怪有時候我們就是追求「可以用就好了」，因為不好用所需要的補償成本對廠商來講根本不高阿
等到真正不能用的時候再來思考怎麼辦
如此一來就知道為何能不換就不換了，我也不需要花心力去想有的沒的
畢竟這僅是一個簡簡單單的報名系統而已
或許好久以前寫的，也不需要更新，反正每一次能辦活動就好了，資料的收集以及輸入都是工讀生解決，當中的錯誤也就只是打打電話確認(直接再請電話工讀生或正職自己加班)
不然直接忽略問題，等活動開始現場人來了再說
也讓我想到，dirty data真的是無所不在，也如何的惱人XD
這又讓我延伸的想到
之前接觸一個傳產進行數位化的過程
要建構一個資料庫
需要不停的追求「甚麼是需要的資料」
有一些是不需要收集的，可以進行回推，或是對決策沒有幫助
有一些是很重要的，會影響到operator操作機台的方式，或者讓工廠可以進行預測分析，進而知道該接多少量該怎麼生產之類的
光是要解決建立怎樣的資料庫就花上幾個月
要跟老師傅或廠長接觸，了解一些know how跟決策環境，還有整個過程能不能透過資料庫來trace，比如說成品壞掉了可不可以找出來是哪一個步驟壞了
當時並沒有體會到建構資料庫的重要性，畢竟我只是在旁邊觀察
如今
因緣際會去當一個小小打字工讀仔
就體會到
所謂做得好的資料庫，完全不是可以用就好
操作便利性、正確性、要精簡
真的頗有學問
雖然不會讓我想要去研究資料庫，或更深入去學習SQL之類的
但也能發現透過大架構去思考資料需要怎麼樣連結的時候
真的是要有點想法的
未來或許可以朝著顧問的目標去學習了解一件事情的脈絡
也會算是個挑戰
今天不只是打工賺點小錢而已
讓我算是結合所學，不專業的體會了一下XD
夢的自言自語幻想世界。
2019.1.17
創作內容
體會設計資料庫的重要性
家裡蹲遊記 (5)
