Shulou(Shulou.com)05/31 Report--

What are the relational database design specifications? in view of this problem, this article introduces the corresponding analysis and solutions in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

1. The scope of addition and deletion of each table should be carried out in this table as far as possible.

This principle is also somewhat contrary to the three paradigms, but the benefits of doing so are obvious.

First, from the point of view of cost, the cost of adding, deleting and changing is usually lower than that of multiple tables.

Second, it is convenient to develop, in the data storage process, if multiple table operations are involved, the more tables, the more code to deal with business logic, and the more difficult it is to develop.

Third, the maintainability is high, which coincides with the second point, but it is because the business code of a single table design will be relatively simple, so it will be relatively easy to maintain in the future. On the contrary, the business code of multi-table is numerous and complicated. Future maintenance will also be very difficult.

2. The corresponding relationship should be reflected through the primary key, and the process order should be reflected.

The biggest problem of enterprise application is to sort out the business and sort out the corresponding relationship between business modules. In the database, the primary key contained in the table should reflect not only the corresponding relationship, but also the logic of the generation order or process order.

3. Each table represents a business module as far as possible, and try to record all the fields in the module.

This principle is inferred from the first principle, because the cost of adding, deleting, modifying and querying in this table is small, so if a table is sufficiently cohesive, then the table should record all the fields in the module as much as possible.

Tips:

If there are too many fields in the business module, you can do sub-table processing, but if it is designed separately in the first place, then the processing will be very troublesome.

4. Intermediate tables cannot be used at will

Under the premise of fully following the three paradigms, our design will have a lot of intermediate tables (relational tables). However, if one of the two tables has frequent additions and deletions, then in terms of efficiency, such a design is not qualified. Such a design does reduce a lot of data redundancy, but it also greatly increases the cost of adding, deleting and modifying each piece of data. Therefore, from the general enterprise application scenario, the intermediate table can not be used at will.

By understanding the usage defects of intermediate tables, we also know when intermediate tables can be used. When neither the left table nor the right table needs to be changed very frequently, but there are frequent query requirements for joined tables, we can use intermediate tables to improve query efficiency and reduce data redundancy.

The answers to the questions about the relational database design specifications are shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.