This article was reproduced from: http://www.webdevs.cn/article/92.html
———— because of laziness, so thinking
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
- Count the number of orders that the user has not paid in each type of order
- Calculate Total Quantity
- Displays information about all unpaid orders for the current user over a period of time in the list (implemented as above)
- To count all the unpaid order information for that user during this time period in all types of orders
- In the business code in order to sort by time (there will be a variety of orders inside the same field information may be different naming cause business code inside the conversion [such as: write-off order call
order_id
, life payment order is called orderId
], will be based on the order type to judge separately .... All kinds of pain)
An exception to this is an unknown factor: a new type of order is added to the list of unknown types that continue to be added, and the implementation of the above will be followed by a new 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 teachers, students and other personnel information, as far as possible to meet the future expansion. (Hint: Please write 3 ways, and write down the pros and cons separately)
- Getting Started implementation
Idea: Design a table to store personnel information, define type
fields, 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
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)
- 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 currently using the second way to achieve, resulting in some businesses do some not very爽
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:
- Create a parent order form by abstracting the public attributes of all orders (e.g., order number, order time, orders status, order type, etc.).
- Create various order-specific attribute tables (various types of order unique attributes)
- Relationship: The parent order table and the order form a one-to-one relationship (each order table can be in the parent order table has 1 of the corresponding)
The above approach will be able to meet most of the business situation
As in the above two query cases:
- Count the number of orders that the user has not paid in each type of order
- Displays information about all unpaid orders for the current user within a certain time period in the list
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