This chapter is suitable for junior engineers and intermediate engineers, please feel free

preface

  • Ask [not save the price field can not? Directly query the commodity table to obtain the price]
  • Answer [If the price is updated, users should be reminded of the floating information of the product. You can choose to directly update the shopping cart, or set up a separate table to record the updated price and information, similar to JINGdong]
  • Ask [table query can know from the list of goods on the shelf]
  • Answer [goods do not exist how to unite, will only the logic of the whole complex, including the future price reminder, no stock reminder, takedown reminder, shopping cart how to query has become a problem]

business

From the point of view of business, it is reasonable to check multiple tables or save single tables. List the relevant part of business on the shopping cart below

  • Low inventory alert (increased probability of payment)
  • Price reduction alert (increase probability of payment)
  • Reminders of merchandise removal
  • Merchandise coupons or other activities related to the product (to improve the probability of payment)

In technical terms

The price to remind

Multi-table price reminder needs a third table to support < commodity modification Record table >

More table

At this time, the goods in the shopping car are associated with the commodity list, and the detection system needs to add the goods to the shopping cart after the detection result when the price is modified by the merchant. By the way, it can query the price before the modification by the merchant, calculate the price difference, and send it to the queue or other means. The user receives the notification of price reduction to stimulate consumption. If you need to add a new service, ask the user how much the price has been reduced since the user added to the cart. Do you need to add a record table to the shopping cart? This continuous multi-level association seems to be no problem, but actually the business is coupled, SQL is associated with N tables at a time, let alone if skUs and SPUs are added at this time. It is untenable at future magnitude increases, and it is not easy to scale.

Single table

[my design is not the best, only for reference), in the future business of growing into consideration, I will be the price with the title and the commodity SKU added to the shopping cart in the table, the merchants do not need to care about the other tables, when modifying retrieval related to modify the goods shopping cart directly, take out the price, price difference calculation, prompting the user. If you calculate the actual price of the shopping cart, this is the same operation as above, and these two requirements are actually a solution for a single table design. The query is also an implementation of an SQL statement.

Of course, we still need to be associated, do not know the future of a day to use the top? There are many scenarios where the title and content are stored directly, similar to stores and goods collected. No matter what the seller does, the user’s shopping cart and order cannot be moved. This is the benchmark.

Goods from the shelves

Goods off the shelf, the user’s shopping cart is actually unable to move, a cat’s approach is to make it gray, let the user delete. There are many kinds of businesses, the title of goods, pictures or classification modification, all belong to the shelf, then the multi-table associated query will be completely invalid. In fact, the removal of goods should be directly notified shopping cart removal (gray), not associated query whether to remove. If you do, you still need to make some tables to keep track of it.

I’m not saying you don’t need to keep records. Instead, the recorded table is not actually participating in the business query.

logic

Logic here refers specifically to the architecture of code writing. In PHP, for example, you can refer to my previous article segmentfault.com/a/119000001… On the logical side, there are many aspects to consider, such as SQL performance, code performance, server performance, etc. Try to avoid multiple table queries.

reusability

The definition of Baidu Encyclopedia is

Reuse, also known as reuse, means repeated use. At present, the reuse rate of general software is not high, especially in China. The benefits of reuse include higher productivity and consequent cost reductions, higher software quality (errors can be corrected more quickly), and improved system maintainability when reuse is used properly.

In the design of shopping cart, reuse mainly refers to the storage mode of commodity information, avoiding multiple queries to the linked table, and the withdrawal will be more obvious in the sub-database of the table after a large volume of business.

scalability

The definition of Baidu Encyclopedia is:

Well-designed code allows more functionality to be inserted into place when necessary. The goal is to overengineer the code for future changes that may be needed.

Normal shopping cart, goods, coupons are independent systems and functions, not as goods in the shopping car. Reality and logic do not go hand in hand. Assume that in real life, items are just put in the shopping cart, if not checkout, still do not belong to their own. In order to facilitate the expansion of more business, try not to “stick” between functions at the beginning of the design.

maintainability

The definition of Baidu Encyclopedia is:

System maintainability is a measure of how easy a system is to fix (recover) and improve. The so-called repairability refers to the possibility of eliminating (or restraining) the failure to repair and returning to the original normal operation state after the failure of the system. Improvability means that the system has the possibility to accept the improvement of existing functions and add new functions.

Shopping carts are also designed to allow for changes in the business functions of future items. Instead, simply add its properties to the shopping cart.

The complexity of the

The initial design determines the complexity of future development and refactoring. Function to function, system to system to avoid direct correlation.

statistical

Later data statistics and calculation will also be affected by the early design.

Thank you

Thank you for reading this. In the next post, I will talk about the product design of e-commerce system. Any questions can be asked in the comments section. thank you

communication

There is life, there is code.

Spread the positive energy of technology and continue to learn new knowledge.