Re: [討論] 資料庫和SQL的專業是不是很不被重視?

[littlethe (東周流浪漢)]

我講講我看法吧

※ 引述《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://www.ptt.cc/bbs/Soft_Job/M.1511891087.A.01D.html
推 MephistoH: 有道理
推 femlro: 讚讚讚 跟下棋一樣
推 Hordor: 資料檢查講的是若設 fk/unique key 等限制，若違反，db就
→ Hordor: 不給操作
→ Hordor: 簡單說就是資料庫層的資料防呆
推 te426odin: TO樓上 :這時候RD會跟你說我們有檢查了 你不要那麼雞婆
→ te426odin: 好不好，這樣我們要測試很麻煩XD
推 a47135: 隊友一堆北七的時候資料庫層防呆應該會有點好處XD
推 atpx: 資料庫防呆很沒彈性, 若是在嚴謹的大公司反而拖慢作業效率的
→ atpx: 缺點會被放大
推 ssadow: 可是資料庫不防呆, 當很多地方要這些資料時就會想哭了