1.資料庫里一張表A，可能一月就會產生幾千萬條資料
2.A表的編號欄位（code）規則不統一，有些編號有帶日期，有些沒有，業務操作上經常會通過A.code查詢資料
3.還有其他幾張大表和表A有外鍵關聯，存盤表A的ID
我用的資料庫方案是用ef core來做的，資料庫型別為PostgreSql，基于ef core有沒什么好的設計方案？
---------------------------------
我的想法
1：對開發調整最小的應該是進行表磁區，表磁區根據編號（code）范圍磁區，但是因為編號（code）規則不統一，作為磁區欄位是否不合適？如果這種表磁區就能解決，應該是最優的解決方案
2：如果code無法作為范圍磁區欄位，對于A表按照不同規則分表，這樣每張表的格則統一，然后再按照code進行表磁區？這樣做的話ef core如何設計能更好支持（開發不用過多關注資料到底存在在哪張表，由工廠類或者其他方式處理），而作為其他關聯表又如何處理？
3：分庫：分庫作為后續資料歸檔時使用，是否暫時先不考慮？
uj5u.com熱心網友回復：
每個月都有千萬資料的話，你這個肯定要分表分庫了，這個直接靠EF已經不靠譜了，這種我覺得還是改成Dapper進行互動吧，另外索引記得要測驗是否一定生效了，如果Code可以確認的話，那可以考慮將Code的Hash結果，然后首字母作為磁區標準，當然也可以考慮轉成int后取模作為磁區標準uj5u.com熱心網友回復：
你可以按照code的 hashcode來進行索引和磁區。我只能說試試看吧。
uj5u.com熱心網友回復：
hash 磁區是個辦法。uj5u.com熱心網友回復：
如果可能你對業務進行磁區，把讀寫做分離后在分實體。uj5u.com熱心網友回復：
改不動了，改動太大了，專案已經上線了，要盡量小的改動
uj5u.com熱心網友回復：
嗯，可以考慮下
uj5u.com熱心網友回復：
這是一個解決方案的問題，和具體使用什么框架技術沒有直接的關系了uj5u.com熱心網友回復：
你的code沒有規則的話很難想象。。。當初設計表的人就是個混子。。。轉載請註明出處，本文鏈接：https://www.uj5u.com/net/8429.html
標籤：.NET技術前瞻