我講講我看法吧
※ 引述《trueQoo (幸運之神)》之銘言：
: 資料庫這種情況很常見，就是不懂設計下的產物
: （學校沒教是一種情況）
: 然而，你還不能說他們不懂設計，他們會反過來說是你不懂設計
: （悶了）
: 資料庫界的奇怪現象
人天生自大,
這個真的是人性,
每個人都覺得自己懂,
說別人不懂,
大家在公司也一定看過那種完全沒碰過程式的人講得一嘴好程式,
要他來寫,就縮起來說自己不是工程師不寫,你寫的時候,他意見又一大堆
會寫程式就一定懂嗎?
也不是,寫程式很多人是亂寫的...
懂不懂很主觀,
我自己判斷誰懂不懂的方法有兩個,
一個是看他有沒有在進修,有沒有在不斷學習,
另一個是看他會不會與非工作上的工程師交流,
像我們利用私人時間在網路上討論聊技術,就是一種交流,
不管是第一個還是第二個,
關鍵都在於走出公司向外面的世界學習,
有錯就改,有好的就學,
而且是要有"實作",不是只是聽聽聊聊而己,
若是只會躲在公司裡閉門造車,
自己土法練鋼搞出了個東西就覺得自己很利害,
這個就是不懂,
而且會愛說別人不懂,
遇到問題就會想找倒楣鬼擦屁股
: 1.拿掉 pk 與 fk，說這樣效能會比較好（好在哪？）
: 2.多個欄位合起來設定一個 pk
設組合鍵是可以的,
組合鍵缺點是會比較慢,
但主鍵的功能並不是只是增加效能,
同時也有防重覆的功能,
所以設組合鍵來防重覆是OK的,
例如記錄一家店有賣那些東西,
這種表,把店號和商品號設為組合鍵是沒問題的,
若組合鍵設到5個以上的話,
會影響到速度或維護的話,
再改成單一主鍵配合索引處理
: 3.一個人有多個電話，會設計成 tel1 tel2 tel3 多個欄位
我會喜歡研究資料庫,
有很大的原因是因為資料庫是很講究"策略"的,
比較沒有固定的做法,
要考慮的因素很多,
很靈活的,
我早年是走UI的,
走UI覺得太雜太悶,有意見的人太多,就改走資料庫了...
像你舉的電話的問題,
設計成tel1,tel2也沒什麼不好呀.
如果需求上只是要一個主電話,一個備用電話,
真的設在一張表就好...
就算有人有5個電話,他也只要寫2個就好,不用全寫
但是,假設我們今天要建一個罪犯檔案,
罪犯逃來逃去,搞不好會有10支電話,
而我們又必需要記錄到罪犯所有的電話,
這時候就需要把電話另外建表了
: 4.為了正規化而設計資料庫，而不是為了使用者需求，也不是為了效能
我以前唸書時教到正規化,
只知道正規化,
但後來考證照時,
講師講到反正規化,
我才知道反正規化,
我才知道正規化只是個選擇,
正規化也有缺點,
反正規化也未必不好,
因為各有優缺,
所以要視情況設計,
資料庫設計時,
要能想到一年後的狀況,
甚至五年後的狀況,
這就是資料庫迷人的地方,
沒有策略觀念的人做不好資料庫
: 5.用應用程式去做原本資料庫該做的資料檢查
: 讓我想到，這種資料庫品質想要做什麼資料倉儲，我也是覺得很不可思議
我是不太了解你講的資料檢查是什麼,
比較嚴謹的話,
確實在資料庫裡要做檢查,
但如果成員對資料庫不熟,
那用他擅長的工具來做檢查,
也是可以的,
最終還是要回到問題有沒有解決上,
不應該是型式