表結構設計問題

一個表結構設計，有些不懂怎麼做了，請問大家：

有一個模組，下面有6張不同類型的表，它們都有共同的字段5~6個。 （每張表的數據都超過3000萬)

1、新建一個總表，把這5個字段都分出來,再加個日誌類型ID來操作6個表（第三範式），做聯合查詢。

<code>优点：可以方便更新共同字段、统计数据
缺点：数据多了，联合查询是个问题
</code>

2、單獨6個表

<code>优点：（查询单表不用联合、插入也方便一些)
缺点：统计和更新共同字段状态、以及做报表什么之类的都需要 一次性去操作6个表
</code>

該怎麼選用那種方式好一些呢, 或者其它建議？

謝謝！

回覆內容：

一個表結構設計，有些不懂怎麼做了，請問大家：

有一個模組，下面有6張不同類型的表，它們都有共同的字段5~6個。 （每張表的數據都超過3000萬)

1、新建一個總表，把這5個字段都分出來,再加個日誌類型ID來操作6個表（第三範式），做聯合查詢。

<code>优点：可以方便更新共同字段、统计数据
缺点：数据多了，联合查询是个问题
</code>

2、單獨6個表

<code>优点：（查询单表不用联合、插入也方便一些)
缺点：统计和更新共同字段状态、以及做报表什么之类的都需要 一次性去操作6个表
</code>

該怎麼選用那種方式好一些呢, 或者其它建議？

謝謝！

數量量有這麼多的情況下
建在一張表裡，同時把資料仍到es裡去，讀的時候讀es
更新操作表，同時把更新過的資料同步到es

問題不是很清楚。

1. 六個表是什麼關係，為何統計更新共同欄位需要一次性操作6個表。

2. 目前是什麼樣子的，效能如何，會有什麼樣的查詢和更新語句。

其實資料到3千萬可以考慮分錶了。

分錶更好一些，資料量多了分錶是不可避免，而且分錶的方式也還行，如果是需要考慮經常性檢索需要，可以考慮按照經常性檢索的條件方式作為存儲分錶的結構，可以加速統計速度。其他的檢索比較少的方式也只能多檢索幾次了。

鑑於資料量在千萬級別的情況，可以考慮定期去執行生成臨時統計表，降低資料庫壓力，加快查詢統計速度。

是什麼場景的數據，電信話單？做 業務統計的話，建議是分錶處理，有時 不見得 非得讓大批量的 表進行笛卡爾積 才可以解決問題