In order to avoid the complex one-to-many-to-many relationship in the database, my design of the database is that the fields in the table have no foreign keys. The relationships are manually related using setters and getters. However, the program is written down and the function can be realized. , but I found that it was very painful to write a lot of getters and setters, or should I not have designed it this way from the beginning
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
This design is very good, you just lack a database abstraction layer, or ROM.
There is a concept in database theory called:CAP.
CAP theory was proposed by Professor Eric Brewer. When designing and deploying distributed applications, there are three core system requirements, and there is a certain special relationship between these three requirements. The three requirements are as follows:
C: Consistency
A: Availability
P: Partition Tolerance
The core of CAP theory is:A distributed system cannot satisfy the three requirements of consistency, availability and partition fault tolerance at the same time. It can only satisfy two of them at the same time.
And most nosql databases compromise on C (consistency).
So it is wise to abandon foreign keys. Foreign keys are to maintain the consistency of all data, but many times we do not need the data to be consistent in real time at all, we only need to ensureeventual consistency.
http://www.csdn.net/article/2...
http://duanple.blog.163.com/b...
1. Nowadays, the Internet basically does not use foreign keys.
2. For get set problems, you can try Lombok
In practical applications, we generally use programs to control foreign keys. Not at the database level.
First, foreign keys (here specifically referred to as mapping relationships) in relational databases are still very useful.
Second, foreign keys (here specifically referred to as foreign key constraints) should not exist.
There are fewer and fewer applications using foreign keys. There were quite a lot of them 10 years ago. Mainly due to business independence considerations. I like to put the business entirely on the application side, and the database is only used for persistence.
When I started working on some project databases more than ten years ago, the databases were also involved in the business, but later I found that it was very painful to maintain. Later, during project maintenance, in order to deal with all problems, a database specialist had to be added. This issue was also raised in the project summary. The cost of database specialists is very high.