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

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.86.244.136 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1511891087.A.01D.html