Should a table with the same logical structure be synthesized?

Source: Internet
Author: User
When the new company is doing the project, the technical leaders are required to synthesize a table with the same logical structure.
For example:

comment #评论表    id    user_id    content    reply_id    add_timemessage #私信表    id    user_id    reply_user_id    content    reply_id    add_time

Two tables have the same structure, and then the leader merges the same table with the same structure, and then adds a type for processing, which reduces the same code. I think this is not very good, in case after the increase of the function will be more headache, if it is to reduce the code, two identical structure of the model inherited the same model also can be, not to the function of different tables merged into a bar, later if in order to save performance, not still have to split the table?

What do you think of this?

Reply content:

When the new company is doing the project, the technical leaders are required to synthesize a table with the same logical structure.
For example:

comment #评论表    id    user_id    content    reply_id    add_timemessage #私信表    id    user_id    reply_user_id    content    reply_id    add_time

Two tables have the same structure, and then the leader merges the same table with the same structure, and then adds a type for processing, which reduces the same code. I think this is not very good, in case after the increase of the function will be more headache, if it is to reduce the code, two identical structure of the model inherited the same model also can be, not to the function of different tables merged into a bar, later if in order to save performance, not still have to split the table?

What do you think of this?

I think all the questions about database design should be considered from the perspective of "query". That is, you want to anticipate how you will query the table in the future, and then consider how to design the structure.

Back to the question, you can consider:

    • Comments are always queried with private messages
    • Is it necessary to find a comment when looking for a private messages
    • It is necessary to use the same sequence for comments and the ID of the private messages

The landlord can think in turn, split the table.
Some of the traffic is larger than the station, the log title and description is a table, the log content is a table
Because people do not necessarily see the log content when they access the log list, many log queries can create a waste
Table merging, I think the main is to see them in the query, whether it is necessary to often display together, if only to reduce the amount of code, this is not necessary, as the system user comments and the content of the private messages increase, will inevitably affect the efficiency

A table in a database, typically representing a business object, if two business objects are of the same type, but different types have individual fields, consider a common table, and then distinguish them with a type field.

In the landlord's example, comments and private messages are clearly not a business object, the table inside the content,reply_id although the name is the same, but the representative of the business meaning is completely different, so the proposal is divided into two tables. Otherwise the late maintenance of the time is very troublesome, operation of the people at first certainly do not understand, why the same field, in the database according to another type field has a different meaning.

  • Contact Us

    The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

    If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

    A Free Trial That Lets You Build Big!

    Start building with 50+ products and up to 12 months usage for Elastic Compute Service

    • Sales Support

      1 on 1 presale consultation

    • After-Sales Support

      24/7 Technical Support 6 Free Tickets per Quarter Faster Response

    • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.