The article is reprinted, original address: https://zq99299.github.io/note-architect/ztc/01/07.html#%E8%A1%A8%E7%BB%93%E6%9E%84-sql- %E8%84%9A%E6%9C%AC
- Performance impact: In a distributed system, database interaction is inevitable, and foreign keys may cause cross-database queries, which will increase the complexity of the system and Response time.
- Hot update: For non-stop maintenance requirements, using physical foreign keys may cause access failure to unupdated instances when updating data, because foreign keys are strongly consistent. .
- Conflict between foreign keys and distributed systems: Foreign keys require data to be logically consistent, while distributed systems usually pursue eventual consistency. This makes it difficult to use physical foreign keys in distributed systems.
- Reduce coupling: By avoiding the use of physical foreign keys, the coupling between databases can be reduced. This makes the system easier to expand and maintain.
- Logical Foreign Key: Although a physical foreign key does not exist, a foreign key relationship may be logically required. For example, there might be a logical foreign key relationship between the users table and user addresses.
- Data sharding and sharding: Avoiding physical foreign keys can make data sharding and table sharding easier to implement. There are no physical foreign key restrictions, and related data can be dispersed into different databases or tables, improving the flexibility of the system.
In general, in large-scale Internet projects, avoiding the use of physical foreign keys is to improve the performance, maintainability, and scalability of the system. However, logical foreign keys and appropriate indexes can still be used to ensure data consistency and query efficiency. When implementing sub-database and sub-table, the above difficulties can also be avoided through reasonable design and planning.