1. The table name is generally named after the module name_specific table name
2. The table name is named after the English name, not too long
3. Do not use tab or tb as the table prefix
4. Some tables used as many-to-many connections can use two The prefix of each table is used as the table name
5. When there are a small number of recurring values in the system, use dictionary tables to save storage space and optimize queries.
6. Some special fields can directly use Chinese characters instead of codes to improve query efficiency
7. When naming tables, use singular form to express the name
8. Such a table should be established in the database, which is the field information of the database itself. Description, which is a table of the database design document, is convenient for query and use. If there is anything unclear, you can directly query from the database. If the database document is lost or the comment is lost, it can be used again.
9. Each table should have a primary key. The primary key is preferably a number, and it is incremental. The primary key of many tables is encoded with 32-bit characters. The purpose of doing this is more for security considerations.
10. The relationship between basic tables and their fields should satisfy the third normal form as much as possible. However, database design that satisfies the third normal form is often not the best design. In order to improve the operating efficiency of the database, it is often necessary to lower the paradigm standard: appropriately increase redundancy to achieve the purpose of exchanging space for time.
11. If there is a many-to-many relationship between two entities, this relationship should be eliminated. The way to eliminate it is to add a third entity between the two. In this way, the original one-to-many relationship has now become two one-to-many relationships.
12. The value method of the primary key PK. PK is a connection tool between tables for programmers. It can be a number string without physical meaning. It can be realized by adding 1 automatically by the program, or it can be a field name or a combination of field names with physical meaning.
13. The middle table represents the table for storing statistical data, which is designed for data warehouses, output reports or query their own results
14. The operation log table and login log table are two necessary tables in the database, and this record also needs to be further preserved. . There are two situations, one is the operation log specific to a single field, and the other is the operation log of the entire table.
The way to prevent database design from being patched is the "three less principles":
(1) The fewer tables in a database, the better. Only when the number of tables is small can it show that the E-R diagram of the system is small and refined, and redundant redundant entities are removed, a high abstraction of the objective world is formed, and the data integration of the system is carried out to prevent patching. the design of;
(2) The fewer fields of the combined primary key in a table, the better. Because of the role of the primary key, one is to build the primary key index, and the other is to serve as the foreign key of the sub-table, so the number of fields for the combined primary key is reduced, which not only saves running time, but also saves index storage space;
(3) The fewer fields in a table, the better. Only when the number of fields is small can it show that there is no data duplication in the system, and there is little data redundancy. More importantly, urge readers to learn to "change columns into rows", which prevents the fields in the subtable from being pulled Enter it into the main table, leaving many vacant fields in the main table. The so-called "column to row" is to pull out part of the content in the main table and build a separate sub-table. This method is very simple, but some people just aren't used to it, don't adopt it, and don't implement it.
The practical principle of database design is to find the right balance between data redundancy and processing speed. "Three Shao" is an overall concept, a comprehensive point of view, and a certain principle cannot be isolated. The principle is relative, not absolute. The principle of "more than three" is definitely wrong. Just imagine: if the same function of the system is covered, the E-R diagram of one hundred entities (a total of one thousand attributes) is definitely much better than the E-R diagram of two hundred entities (a total of two thousand attributes) .
Advocating the "three less" principle is to ask readers to learn to use database design technology for systematic data integration. The steps of data integration are to integrate the file system into an application database, integrate the application database into a theme database, and integrate the theme database into a global comprehensive database. The higher the degree of integration, the stronger the data sharing, the less the phenomenon of information islands, and the fewer the number of entities, the number of primary keys, and the number of attributes in the global E-R diagram of the entire enterprise information system.
The purpose of advocating the "three less" principle is to prevent readers from using patching technology to continuously add, delete, and modify the database, so that the enterprise database becomes a "garbage heap" of randomly designed database tables, or a "big yard" of database tables. The basic tables, code tables, intermediate tables, and temporary tables in the database are disorganized and innumerable, and the information systems of enterprises and institutions cannot be maintained and paralyzed.
Anyone can achieve the "three more" principle, which is a fallacious theory of "patching method" to design databases. The principle of "three less" is the principle of less but better. It requires high database design skills and art, which cannot be achieved by anyone, because this principle is the theoretical basis for avoiding the use of "patching methods" to design databases.
Under the given system hardware and system software conditions, the ways to improve the operating efficiency of the database system are:
(1) In the physical design of the database, reduce the paradigm, increase redundancy, use less triggers, and use more stored procedures.
(2) When the calculation is very complicated and the number of records is very large (for example, 10 million), the complex calculation must first be done outside the database, and after the calculation and processing in the C++ language is completed in the file system, it is finally stored in the database and appended to the table to go. This is the experience of telecom billing system design.
(3) If it is found that there are too many records in a certain table, such as more than 10 million records, the table should be horizontally split. The method of splitting horizontally is to divide the records of the table into two tables horizontally based on a certain value of the primary key PK of the table. If it is found that a table has too many fields, for example more than eighty, the table is split vertically, and the original table is decomposed into two tables.
(4) System optimization of the database management system DBMS, that is, optimization of various system parameters, such as the number of buffers.
(5) When using the data-oriented SQL language for programming, try to use optimization algorithms. In short, to improve the operating efficiency of the database, efforts must be made at the three levels of database system-level optimization, database design-level optimization, and program implementation-level optimization.
Primary key design:
1. It is not recommended to use multiple fields as the primary key. A single table is fine, but there will be problems with the relationship. The primary key auto-increment is high-performance. There is a problem with import and export.
2. In general, if there are two foreign keys, it is not recommended to use two foreign keys as the joint primary key, and create another field as the primary key. Unless this record has no logical deletion flag, and the table will always have only one record of this joint primary key.
3. In general, an entity cannot have neither a primary key nor a foreign key. In the E-R diagram, the entity at the leaf part can define a primary key or not (because it has no descendants), but must have a foreign key (because it has a father).
The design of primary key and foreign key plays an important role in the design of global database. When the design of the global database was completed, an American database design expert said: "Keys are everywhere, and there is nothing but keys." Highly abstract idea of system core (data model). Because: the primary key is a high degree of abstraction of the entity, and the pairing of the primary key and the foreign key represents the connection between the entities.