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

[gn01838335 (寂靜的生存者)]

https://goo.gl/WPgUPn

這是一位美國老DBA告訴你資料庫沒有外鍵的九個理由。

甚至在salesforce他們的transactional  manner資料庫也是沒有外鍵的喔

意味著資料完整性是處理在別處

底下回覆有句話很有意思

我認為用web和全端工程師眼光覺得外鍵夠用

但是到了資料量到某個級距，甚至建立資料倉儲，就要開始分層處理。

好啦我也是嘴砲工程師，說真的我認為小企業資料量少用什麼都沒差。

若有資料倉儲層的《軟體》公司想法和設計就會不一樣


考量角度不同，等問題到了再解決問題就好了，keep in simple

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.52.195.71
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1511912575.A.67F.html
※ 編輯: gn01838335 (27.52.195.71), 11/29/2017 07:43:36
※ 編輯: gn01838335 (27.52.195.71), 11/29/2017 07:45:18
※ 編輯: gn01838335 (27.52.195.71), 11/29/2017 07:46:00
推 Clain66: 這作者本身也建議要用其實
推 Clain66: 如果沒有 FK 是出於某種考量過後的決定，那感覺還可以。
→ Clain66: 但你說整個系統都沒有 FK ，我想一定是有什麼問題。
我不是點出transactional是沒有FK，你腦補我說不用FK喔，資料量少你要什麼都可以啊
推 drajan: OLAP跟OLTP write-heavy跟read-heavy 資料庫設計甚至選擇
→ drajan: 都是完全不一樣的 everything is trade-off
→ drajan: 說不出為什麼要用FK 為什麼不用 大概database都不及格
※ 編輯: gn01838335 (27.52.195.71), 11/29/2017 08:28:14
※ 編輯: gn01838335 (27.52.195.71), 11/29/2017 08:29:26
推 Clain66: 呃呃，我文字可能有點讓原PO誤解，在此道歉。我指的是原
→ Clain66: 系列文裡提到的沒有 FK 問題。
推 wtfaha: 原來
→ testPtt: FK就有關聯才有 沒關聯就沒有 這有什麼好爭的