不吐不快

沒想到工作上也能遇到如此奇葩的DB設計

可惜，當初在超過半小時的鬼打牆溝通後，我放棄了

現在嘗到苦果的還是自己，哭哭


1. 完全沒有Foreign Key，也沒有適當的Constraint
1.1  DB不是只用來存資料
還可以描述實體之間的關聯

1.2  只透過程式流程來控制和管理DB
一方面沒有發揮關聯式資料庫的優點
另一方面也可能提高資料異常的機率

1.3  DB的可讀性差
若DB和API由不同成員維護
DB維護人員只看DB schema可能很難瞭解DB全貌
還必須要看API code

1.4  完美的增加API設計複雜度
假設有幾十個Tables之間事實上有關聯
不能用Delete Cascade好可怕的


2. 命名
2.1  Column命名和Table一模一樣
舉例來說：
誰可以告訴我，房子的房子是甚麼意思嗎？

2.2  格式混亂
一份只有4個Table的DB，也可以使用
(a) 字首大寫，其他全部小寫
(b) 字首大寫，後面有些字也用大寫
(c) 全部小寫，單字不分隔
(d) 全部小寫，以底線隔開不同的單字
4種不同的命名規則

2.3  意義不明
只看命名很難懂某些Column代表的是甚麼


啊啊啊啊~ 都想拿來當負面教材了
(未完待續)