Table structure design issues

A table structure design, I don’t know how to do it, please ask:

There is a module with 6 different types of tables below, and they all have 5~6 fields in common. (Each table has more than 30 million data)

1. Create a new master table, separate these 5 fields, and add a log type ID to operate 6 tables (third normal form) and do joint queries.

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

2. 6 separate tables

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

Which method should be better? Or any other suggestions?

Thank you!

Reply content:

A table structure design, I don’t know how to do it, please ask:

There is a module with 6 different types of tables below, and they all have 5~6 fields in common. (Each table has more than 30 million data)

1. Create a new master table, separate these 5 fields, and add a log type ID to operate 6 tables (third normal form) and do joint query.

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

2. 6 separate tables

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

Which method should be better? Or any other suggestions?

Thank you!

When there are so many quantities
Build it in a table, and at the same time transfer the data to es. When reading, read es
update the operation table, and synchronize the updated data to es

The question is not very clear.

1. What is the relationship between six tables? Why does statistical update of common fields require 6 tables to be operated at one time?

2. What does it look like now, what is the performance, and what kind of query and update statements will there be.

In fact, if the data reaches 30 million, you can consider splitting it into tables.

Table splitting is better. When the amount of data is too large, splitting into tables is inevitable, and the splitting method is not bad. If you need to consider the need for regular retrieval, you can consider using the conditions for regular retrieval as the structure for storing split tables. , which can speed up statistics. Other methods with relatively small searches can only be searched a few times.

In view of the fact that the amount of data is in the tens of millions, you can consider regularly generating temporary statistical tables to reduce database pressure and speed up query statistics.

What scenario is the data, telecom bill? When doing business statistics, it is recommended to process it in separate tables. Sometimes it is not necessary to perform Cartesian product on a large number of tables to solve the problem