Should a table with the same logical structure be merged?

When a new company is working on a project, the technical leader asks to merge all tables with the same logical structure into one table. example: {code ...} the two tables have the same structure, and then the leaders merge the tables with the same structure and add a type for processing, which can reduce the same code. I think this is not good ,... when a new company is working on a project, the technical leader asks to merge all tables with the same logical structure into one table.
For example:

Comment # comment table id user_id content reply_id add_timemessage # private message table id user_id reply_user_id content reply_id add_time

The two tables have the same structure, and then the leaders merge the tables with the same structure and add a type for processing, which can reduce the same code. I think this is not good. It will be a headache to add functions later. If it is to reduce the code, the two models of the same structure tables can inherit the same model, I don't want to merge tables with different functions into one. If I want to save performance in the future, do I have to split the tables?

What do you think?

Reply content:

When a new company is working on a project, the technical leader asks to merge all tables with the same logical structure into one table.
For example:

Comment # comment table id user_id content reply_id add_timemessage # private message table id user_id reply_user_id content reply_id add_time

The two tables have the same structure, and then the leaders merge the tables with the same structure and add a type for processing, which can reduce the same code. I think this is not good. It will be a headache to add functions later. If it is to reduce the code, the two models of the same structure tables can inherit the same model, I don't want to merge tables with different functions into one. If I want to save performance in the future, do I have to split the tables?

What do you think?

I think all questions about database design should be taken into consideration from the perspective of "query. That is, you need to predict how you will query the table in the future, and then consider how to design the structure.

Back to the question, consider the following:

• Check whether the comment always starts with the private message
• Is it necessary to search for a comment when searching for a private message?
• Is it necessary to use the same sequence of comment and private message IDs?

The landlord can think about table splitting in turn.
For some websites with relatively large traffic volumes, the log title and description are a table and the log content is a table.
Because when others access the log list, they do not have to view the log Content. Therefore, a large number of log queries may cause a waste.
In my opinion, table merging mainly depends on whether they need to be frequently displayed together during query. If it is only necessary to reduce the amount of code, as system user comments and private messages increase in the future, efficiency will inevitably be affected.

A database table generally represents a business object. If two business objects belong to the same type but have different fields for different types, you can consider sharing a table, then use a type field to differentiate.

In the example of the landlord, the comment and private message are obviously not a business object. The content and reply_id In the table have the same name but have different business meanings. Therefore, we recommend that you divide the comment into two tables. Otherwise, maintenance will be very troublesome in the future. The O & M personnel will not understand why the same field has different meanings in the Database Based on another type field.