Scene
We have multiple types of orders: physical orders, exclusive merchant orders, write-off orders, live payment orders, movie ticket orders, ticket orders, and unknown types of orders that will continue to be added in the future, all stored in different order type tables
Effect
Cause some of the business to be more painful.
Like what:
- Count the total number of unpaid orders for the current user
- Displays information about all unpaid orders for the current user over a period of time in the list (implemented as above)
An exception to this is an unknown factor: the continuous addition of unknown type orders
Each new type of order is added, and the above implementation will add the business code. A variety of egg aches.
Ideas
Last change of job, interview encountered an interview problem, as follows:
"Please design a database to store the information of teachers, students and other personnel, as far as possible to meet the future expansion." (Hint: Please write 3 ways, and write out the pros and cons separately) "
1. INTRODUCTION implementation
Idea: Design a table to store personnel information, define the Type field, to distinguish between teachers and students
- Advantages: Simple, can deal with the future of various inquiries
- Cons: Too many data redundancy fields, slow query speed
2. Common implementations
Idea: Design Two tables: A storage teacher, a storage student (the most common way)
- Advantages: All this, the advantages of a lot of natural
- Cons: Some queries are somewhat difficult to implement. (e.g.: Query for new teachers and students in the last time period and sort by time)
3. Object-oriented approach to implement
Idea: Design 3 tables: Staff table, teacher-specific attribute table, learning Acisti has attribute table
- Advantages: The sum of the advantages of the above two methods
- Cons: Unknown
Solution Solutions
Back to see our mall's order form with the above incomparable acquaintance, is now using the second way to achieve, resulting in some business is not very cool
If the other way of doing it in a third way, everything will be fine again.
The third approach is implemented using an object-oriented approach:
The above approach will be able to meet most of the business situation
As in the above two query cases:
Implemented here because all can be obtained in the parent order table, will be extremely easy, the business code inside the sorting, field conversion and other problems also solved
Advantages
- Strong ability to achieve business requirements
- Extensibility features, a new type of order in the future, only need to add a value to the order type in the parent order table, in the newly added order-specific attribute table
- Business code will change small or no changes
Design database with object-oriented thinking mode