1樓：王璐
你所說的符合正規化的設計肯定是設計的第一步，之後的設計要看業務具體怎麼用這些資料。
馬上就能想到的幾點是：未完成的訂單備受關注、已完成的訂單不會有修改。
要解決題目中的查詢壓力，簡單的方案是：把未完成單、三月內單、歷史訂單分開儲存。
當然對於前端的處理和快取也能有效減少查詢和查詢壓力。
2樓：
LS的已經回答的很詳細了。
說下我的看法,
order_detail 這個表其實是要和實際業務的紙訂單對應起來，因此會有冗餘字段，比如產品名、位址、使用者名稱、送達位址等，實際查詢使用者查詢訂單的時候只是單錶查詢，不必去關聯其他表。只有後台做資料分析統計才會關聯。如果業務量實在大，訂單資料可以用nosql存放。
然後這個order_detail和order表的歷史資料（假設超過5個月的）對使用者意義不大可以遷到歷史表。
3樓：mysqlops
1.多對多的關係是指實體之間的關係；
2.你這個把相關實體轉換成邏輯設計，也即現在設計的表結構good-order之間的關係屬於1對多的關係，而非多對多的關係；
3.至於訂單號被拆成多條記錄的方式，是否合理？
要看業務需求，有些業務場景採用大訂單號（對外的）+編號（其實也是訂單號，對內的）的模式，比如客戶購買的物品分布在不同的倉庫，那麼就可能採用這個模式，這個時候可以如何做呢？例如：
Outer_OrderID是對使用者公開的，儲存可能是：(Outer_OrderID,Inner_OrderID)，且Inner_OrderID可能採用數字編號+逗號分隔的模式，比如：100010,100011,....
4.good表的設計還會記錄產品的Version，其實在訂單表中也會訪問響應的Version，也即版本號，防止使用者購買完產品，賣家修改產品的描述條款，無法解決日後的糾紛問題...
5.對於提問朋友寫出來的設計方案，也是有人在用的，所以看業務場景及資料量，一般訂單都是會分為熱與冷資料的，並且分開儲存，所以不用過於擔心；
以上建議供參考！
如何遷移超大資料庫表？
正好最近在做類似的東西，沒有接觸過MSSQL，以下主要是MySQL的經驗，前提均是單錶 雖然基本不可能 1.如果可以停機，直接分塊匯出成CSV然後MySQL端LOAD DATA INFILE就好，據說 未驗證 MySQL LOAD DATA的時候是批量匯入後再建立索引，比SQL檔案快的多。2.如果不...
兩個不同的資料庫中有兩個相同的表，如何合併到一起？
吳疆 方法有很多 將資料庫A中的表t1教小，則將t1匯出成csv檔案，然後匯入資料庫B中 如果t2較小則匯出t2 2.大資料資料庫都提供database federation的元件，例如postgresql的fdw等，可以直接在兩個庫之間進行查詢 3.使用ETL工具 以資料之名 異構資料庫的join...
資料庫儲存資料的時候，相同資料分表 分庫的優劣是什麼？
jeff 1.為什麼分庫分表 單個表的資料量過大的時候，會影響操作的效能，這是最直接的原因。對於mysql 來說，單個表的達到多大的資料量才會影響效能，跟資料熱度和設計都有關係。如果是流水式的表，也就是歷史資料很少會更新或者查詢，乙個表上億的記錄數影響都不大，如果是innodb 表最好是自增主鍵，插...