Discussion on several schemes of order number generation

Cut the crap and go straight to the subject.

Scene: The number of new orders per day in the millions, Order table storage table. The order number must be a number.

Scheme One: Business number + year (two digits after year) + month + day + order number. Core logic, create a new order form to maintain the number of new orders per day, generate orders, query from the table to the number of orders, the combination of the other items above the line into the new order number.

Scenario Two: Create a new global order table, hold an ID field, and each time you generate an order number, insert a record in the global order table, using the ID as the order number for the new order.

Both of the above solutions are able to resolve the uniqueness of the order number in the case of a sub-library, but each time an order number is generated, a record must be inserted (updated) in a single table. There are performance bottlenecks under high concurrency.

Programme III: Revised on the basis of programme II. Use the Table_num table as the order number generation table. According to a certain rule, go to one of the tables to generate an order number. For example, the target table is obtained based on the user ID (UID) and the number of tables. Then insert a record in the target table getting the ID to get the id* table number + (user id% table number) Gets the final order number. Order_no = (uid% tale_num) * table_num + (uid% table_num). Somewhat, the operation of a single table is dispersed into multiple tables, which improves the concurrency capability of the system.