一个表结构设计，有些不懂怎么做了，请问一下大家：
有一个模块，下面有6张不同类型的表，它们都有共同的字段5~6个。（每张表的数据都超过3000万)
1、新建一个总表，把这5个字段都分出来,再加个日志类型ID来操作6个表（第三范式），做联合查询。
优点：可以方便更新共同字段、统计数据 缺点：数据多了，联合查询是个问题
2、单独6个表
优点：（查询单表不用联合、插入也方便一些) 缺点：统计和更新共同字段状态、以及做报表什么之类的都需要 一次性去操作6个表
应该怎么选用那种方式好一些呢, 或者其它建议？
开发语言：java，支持数据库：Mysql 5，系统架构：J2EE，操作系统：linux/Windows1. 引言 32. 系统的结构 32.1 系统概述 33. 功能模块设计说明 43.1 商品管理 43.1.1 添加商品功能模块 53.1.2 商品列表功能模块 83.1.3 商品关联功能模块 93.
谢谢！
回复内容：
一个表结构设计，有些不懂怎么做了，请问一下大家：
有一个模块，下面有6张不同类型的表，它们都有共同的字段5~6个。（每张表的数据都超过3000万)
1、新建一个总表，把这5个字段都分出来,再加个日志类型ID来操作6个表（第三范式），做联合查询。
优点：可以方便更新共同字段、统计数据 缺点：数据多了，联合查询是个问题
2、单独6个表
优点：（查询单表不用联合、插入也方便一些) 缺点：统计和更新共同字段状态、以及做报表什么之类的都需要 一次性去操作6个表
应该怎么选用那种方式好一些呢, 或者其它建议？
谢谢！
数量量有这么多的情况下
建在一张表里，同时把数据仍到es里去，读的时候读es
更新操作操作表，同时把更新过的数据同步到es
问题不是很清楚。
六个表是什么关系，为何统计更新共同字段需要一次性操作6个表。
目前是什么样子的，性能如何，会有什么样的查询和更新语句。
其实数据到3千万可以考虑分表了。
分表更好一些，数据量多了分表是不可避免，而且分表的方式也还行，如果是需要考虑经常性检索需要，可以考虑按照经常性检索的条件方式作为存储分表的结构，可以加速统计速度。其他的检索比较少的方式也只能多检索几次了。
鉴于数据量在千万级别的情况，可以考虑定期去执行生成临时统计表，降低数据库压力，加快查询统计速度。
是什么场景的数据，电信话单？做 业务统计的话，建议是分表处理，有时 不见得 非得让大批量的 表进行笛卡尔积 才可以解决问题
