1樓：王璐
我覺得不能一棒子打死，要看具體的設計方案而不是題主的一面之詞。
但是使用主鍵而不是索引的做法確實奇葩。
我懷疑是概念建模就有問題導致的。
2樓：vastdata
資料庫設計的時候，設計師希望每乙個鍵值都有具體含義。主鍵要求非空+唯一，現實中很少有具體含義的列滿足這個條件。設計師一般會創造出非空+唯一鍵值的一列做主鍵，就是單主鍵，單主鍵沒有具體的含義。
聯合主鍵中的各列都是有具體含義的，合在一起滿足非空+唯一的約束條件，這麼用不會引入額外的列，但是這幾列多承擔了一項聯合主鍵的功能，使用起來就不靈活了，比如修改其中一列的時候，你就可能遇到主鍵約束的煩心事。
3樓：林瀾葉
這種典型屬於只曉得正規化理論，卻不知實戰是另外一回事。多個鍵並列作為主鍵，無論你是否規範到bc(這種情況規範到第二正規化以上還是需要的)，都應該用乙個噓的唯一單鍵作為主鍵，名義上這最多只能到第三正規化(噓主鍵決定原來的主鍵，候選鍵之間存在函式依賴)，但實際上你可以當成bc，原主鍵的函式依賴全部由噓主鍵替代，讓其退化成普通鍵(認為其不再是決定者)，這立馬變成了單主鍵的bc，並且該噓主鍵用資料庫自增整數代替，效能會更好，邏輯上講也並不影響資料庫設計。
4樓：TruemanLin
你先問問他，你的設計思路是哪一年？ 問他知不知道資料庫設計的正規化規則
單主鍵的好處（相對聯合主鍵）：
1、資料空洞更少，占用空間更少（只針對Innodb引擎）2、各種資料操作更快
3、資料校對時也更快
反過來，就是聯合主鍵的缺點。不過這些跟你說的去重、各種關聯好像關係不大。
有一點你要明白，不管是聯合主鍵還是單主鍵，都是用來唯一標識某一行記錄的。 如果乙個字段可以確定這一行記錄，那就完全沒必要使用多個欄位來坐主鍵。
所以呢，能用乙個字段為主鍵的，就不要使用多個字段做主鍵，多個字段做主鍵沒有任何好處。
5樓：Ryou ikonn
不明白你這個單主鍵和聯合主鍵和你各種去驗重關聯查詢二者有什麼聯絡。
聯合主鍵和單主鍵相比
缺點1、聯合主鍵比單主鍵維護開銷更大，原因很簡單，一棵更大的b樹索引要維護
優點2、按照聯合主鍵的建立順序的查詢，速度更好。原因也很簡單，這個b樹索引更細，能更快的檢索到要查詢的區間。
關係型資料庫，資料庫表設計，兩個表的連線關係是多對多，連線表的設計除了傳統的設計方案外還有其他設計方案麼？或者說有幾種可能的設計方案。
王璐 你所說的符合正規化的設計肯定是設計的第一步，之後的設計要看業務具體怎麼用這些資料。馬上就能想到的幾點是 未完成的訂單備受關注 已完成的訂單不會有修改。要解決題目中的查詢壓力，簡單的方案是 把未完成單 三月內單 歷史訂單分開儲存。當然對於前端的處理和快取也能有效減少查詢和查詢壓力。 LS的已經回...
如何避免資料庫不響應導致資料庫執行緒池和業務執行緒池全部掛起？
資料庫讀寫執行緒做超時，哪怕非同步了，堵住了沒有超時一樣會死。再用個守護執行緒去檢測這些排隊的情況，一旦超出閾值就報警吧。在一般業務併發處理中，能丟擲主業務就丟擲主業務，讓主業務能最大併發處理。當然如果在主業務中資料庫響應很慢，而且持續時間很長，那麼無論執行緒池中多少個執行緒 執行緒無線多也不是什麼...
乙個優秀的關係型資料庫儲存引擎應該具備哪些功能, 達到哪些指標
肖堂 數蠶 資料庫儲存引擎是資料庫的最基礎的部分，是資料庫的各種功能的實現的載體，它的功能包含儲存結構 含索引結構 事務功能，快取機制，監控或分析機制。其中儲存結構和索引結構是最基礎的功能，用於保證資料的完整性，高效性和查詢特性。事務功能應該滿足基礎的事務的基本級別，至少支援最高端別。支援回滾。快取...