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

[stevekevin10 (hippo泡)]

借串問問

※ 引述《trueQoo (幸運之神)》之銘言：
: 資料庫這種情況很常見，就是不懂設計下的產物
: （學校沒教是一種情況）
: 然而，你還不能說他們不懂設計，他們會反過來說是你不懂設計
: （悶了）
: 資料庫界的奇怪現象
: 1.拿掉 pk 與 fk，說這樣效能會比較好（好在哪？）
1. 前公司有說禁止用fk 好像是資料庫一出錯時會很麻煩 這樣是合理的嗎?
: 2.多個欄位合起來設定一個 pk
: 3.一個人有多個電話，會設計成 tel1 tel2 tel3 多個欄位
如果是固定最多可以填三個電話 不能這樣設計嗎?
: 4.為了正規化而設計資料庫，而不是為了使用者需求，也不是為了效能
: 5.用應用程式去做原本資料庫該做的資料檢查
這裡的資料檢查是指甚麼呢?
之前工作上 有些時候會去把資料先大略的撈出來再去做資料檢查及篩選 這樣不好嗎?
: 讓我想到，這種資料庫品質想要做什麼資料倉儲，我也是覺得很不可思議

前公司蠻大的最近也上市了 技術方面感受起來是很專精的 也有DBA 但DB部分似乎跟這篇
有一點小出入 想討論一下

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.138.21.112
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1511860280.A.369.html
推 vi000246: 看權力在誰手上 如果你說三個就三個 那你就這樣開
→ vi000246: 如果上頭想改更多個電話 那你不就自找麻煩
推 ripple0129: 1.不合理，程式難免出錯沒constraint控制資料易有錯誤
→ ripple0129: 或髒資料。2.永遠不會有需求更動可以3.譬如電話格式(0
→ ripple0129: 2),02-，所以用程式也行，沒有絕對一定要用哪邊檢查
→ ripple0129: 看需求討論。
推 abccbaandy: 1.為了塞假資料方便吧...
推 drajan: PK跟FK是用來確保資料完整 至於要在哪裡做資料完整性檢查
→ drajan: 則要看應用 OLTP多做在資料庫層 而OLAP應用多做在ETL層
→ y3k: 我覺得用FK很合理阿....
→ johnny94: 禁止用 FK 不如不要用 RMDBS ，一堆資料庫給你保證的東
→ johnny94: 西都沒了。
推 Clain66: 不用 fk，那想必你的資料表彼此都沒關係
推 Jichang: 以前剛到部門 我問架構師.. 怎麼 db 都沒有設定 fk
→ Jichang: 他說業界沒有再設定 fk 的 ..
→ zg0608x: 真相是程式寫錯資料要刪資料如果有設定fk非常麻煩