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

看板Soft_Job作者 (幸運之神)時間6年前 (2017/11/28 10:37), 編輯推噓19(19推 0噓 26→)
留言45則, 28人參與, 6年前最新討論串3/9 (看更多)
資料庫這種情況很常見，就是不懂設計下的產物 （學校沒教是一種情況） 然而，你還不能說他們不懂設計，他們會反過來說是你不懂設計 （悶了） 資料庫界的奇怪現象 1.拿掉 pk 與 fk，說這樣效能會比較好（好在哪？） 2.多個欄位合起來設定一個 pk 3.一個人有多個電話，會設計成 tel1 tel2 tel3 多個欄位 4.為了正規化而設計資料庫，而不是為了使用者需求，也不是為了效能 5.用應用程式去做原本資料庫該做的資料檢查 讓我想到，這種資料庫品質想要做什麼資料倉儲，我也是覺得很不可思議 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.136.70.105 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1511836657.A.ECC.html
→
11/28 10:42, 6年前 , 1F
推薦用NoSQL
11/28 10:42, 1F
推
11/28 10:57, 6年前 , 2F
所以2的狀況不少？我還以為只有某ERP廠商這麼做
11/28 10:57, 2F
→
11/28 10:57, 6年前 , 3F
可以解釋一下第五點嗎? 有點不是很懂 謝謝
11/28 10:57, 3F
推
11/28 11:11, 6年前 , 4F
第五點資料檢查用程式做沒什麼問題吧
11/28 11:11, 4F
推
11/28 11:11, 6年前 , 5F
一堆公司都嘛這樣 我們公司也是 pk fk 是看心情設的
11/28 11:11, 5F
→
11/28 11:11, 6年前 , 6F
有的有 有的沒有
11/28 11:11, 6F
推
11/28 11:18, 6年前 , 7F
你有沒有看過用程式 rollback 不用 DB 內建功能的XD
11/28 11:18, 7F
推
11/28 11:26, 6年前 , 8F
2. 原本就是有爭議的
11/28 11:26, 8F
推
11/28 11:27, 6年前 , 9F
第5點應該是原本資料庫的check功能不用
11/28 11:27, 9F
→
11/28 11:33, 6年前 , 10F
所以複合鍵現在變成不能用的東西了?
11/28 11:33, 10F
→
11/28 11:34, 6年前 , 11F
我覺得這五點很多都是你個人的信仰問題
11/28 11:34, 11F
→
11/28 11:35, 6年前 , 12F
只是你自己的偏見而已
11/28 11:35, 12F
推
11/28 11:38, 6年前 , 13F
第3點連第一正規化都沒有...算是基本常識啊...
11/28 11:38, 13F
推
11/28 11:53, 6年前 , 14F
第五點應該是可以在記憶體上完成的事情卻用資料庫做
11/28 11:53, 14F
推
11/28 11:54, 6年前 , 15F
第一正規化大部份DB會幫你檢查吧 無法Insert
11/28 11:54, 15F
推
11/28 12:02, 6年前 , 16F
2 未必是不好的，是設計時需考慮的事。
11/28 12:02, 16F
推
11/28 12:03, 6年前 , 17F
哈哈，不是早就說了，文人相輕啊，自己認真的永遠最好最
11/28 12:03, 17F
→
11/28 12:03, 6年前 , 18F
棒，其他都是錯的！
11/28 12:03, 18F
→
11/28 12:04, 6年前 , 19F
還是show薪資單比薪水比較快啦
11/28 12:04, 19F
→
11/28 12:12, 6年前 , 20F
通常人都要踩進自己挖的坑以後 才知道自己不是永遠是對
11/28 12:12, 20F
→
11/28 12:12, 6年前 , 21F
的
11/28 12:12, 21F
推
11/28 12:12, 6年前 , 22F
說穿了，多個欄位的主索引是對主索引的定義就有問題了
11/28 12:12, 22F
→
11/28 12:14, 6年前 , 23F
研發永遠不會只是單一面向去看事情啊，任何事情都有其背
11/28 12:14, 23F
→
11/28 12:14, 6年前 , 24F
後的原因，不去了解不去了解就先批評才是最大問題
11/28 12:14, 24F
推
11/28 12:30, 6年前 , 25F
某些專案為了特殊需求還會刻意anti正規化
11/28 12:30, 25F
→
11/28 12:31, 6年前 , 26F
...你根本自打嘴巴 自以為最好
11/28 12:31, 26F
→
11/28 12:43, 6年前 , 27F
不要認為你有機車了就嘲笑腳踏車和汽車 每個適用不同
11/28 12:43, 27F
→
11/28 12:47, 6年前 , 28F
2 不一定是錯的
11/28 12:47, 28F
→
11/28 12:50, 6年前 , 29F
3～5 也不一定是錯的，而且你 3、4 兩點不是矛盾了嗎？
11/28 12:50, 29F
推
11/28 13:03, 6年前 , 30F
推現象有感
11/28 13:03, 30F
→
11/28 13:09, 6年前 , 31F
1 不常 search 的欄位不用設 key
11/28 13:09, 31F
→
11/28 13:12, 6年前 , 32F
5-->有的公司為了不同客戶的需求和特殊服務,常會這樣做
11/28 13:12, 32F
→
11/28 13:14, 6年前 , 33F
商用的資料庫系統非常樂見越多人用這個方式越好,還主動
11/28 13:14, 33F
→
11/28 13:15, 6年前 , 34F
更新API,更過分的還送教學影片~公司常常都會不用白不用
11/28 13:15, 34F
推
11/28 13:34, 6年前 , 35F
挖靠這裡也釣的到脆瓜大
11/28 13:34, 35F
→
11/28 14:38, 6年前 , 36F
2,5 真的未必是錯的！
11/28 14:38, 36F
→
11/28 15:49, 6年前 , 37F
第三點遇過一開始需求這樣然後又上加
11/28 15:49, 37F
→
11/28 15:50, 6年前 , 38F
問題是已經有資料了而且還不少 只好就……xd
11/28 15:50, 38F
推
11/28 17:07, 6年前 , 39F
這世界上沒有anti正規化這種東西 只有denormalization
11/28 17:07, 39F
→
11/28 20:39, 6年前 , 40F
充滿偏見的低能文章，肯定年薪低
11/28 20:39, 40F
推
11/28 23:47, 6年前 , 41F
哇 這篇真的標準的自以為懂
11/28 23:47, 41F
推
11/29 09:07, 6年前 , 42F
半桶水響叮噹
11/29 09:07, 42F
推
11/29 10:18, 6年前 , 43F
@drajan 感謝提供精準用字 orz
11/29 10:18, 43F
→
12/12 01:09, 6年前 , 44F
2叫做複合主鍵, 3.看需求再決定要不要拉另一個table吧
12/12 01:09, 44F
→
12/12 01:11, 6年前 , 45F
4.跟3互相矛盾了好嗎? 5.先學一下SQL Injection好嗎?
12/12 01:11, 45F
‣ 更多 trueQoo 的文章
文章代碼(AID): #1Q7ClnxC (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 3 之 9 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共9篇)
‣ 更多 trueQoo 的文章
文章代碼(AID): #1Q7ClnxC (Soft_Job)