Several rules for order naming:
1. No repetition.
I believe everyone understands this point, and the uniqueness of the order does not need to be explained.
2. Security.
Your order number cannot reveal the real operating information of your company. For example, if your order is a serial number, then others can infer the overall operation of your company from the order number. Therefore, the order code must be incomprehensible to anyone except a small number of people in your company. Refer to the coding rules of JD.com and Taobao. Basically, others can't figure out what it means.
In fact, the best leak-proof coding rule is not to add any data related to the company's operations in the coding.
3. Large-scale random codes cannot be used.
When many people analyze the order coding rules, the first thought must be non-repetitive uniqueness, then the second thought may be security, and the third thought that satisfies the first two at the same time is random code. Because the large-scale random code is randomly generated, it doesn't matter if it has no meaning in itself, so it doesn't matter if it leaks. But in fact, this encoding rule will have big problems in implementation.
The random code meets the second security requirement. In order to meet the first non-repeating feature, it is necessary to compare whether the historical data is repeated when generating the random code. If the number of your orders reaches 100,000 times, every time you generate When encoding an order, you have to compare 100,000 pieces of historical data, and you can imagine what huge problems it will cause.
But can't random codes be used in coding? Small-scale random codes can be used, such as 2~3 digits. This kind of random code is generally used in combination with serial numbers, etc., and its main function is to hide the real data of the serial number.
PS: Thanks to @马迷@dad ni @bao xu (I don’t know why @不起) for the discussion here. Ma Chi actually tested and estimated the time it takes to generate random codes and detect repetitions at the nanosecond level. But I still maintain the original point of view, and feel that there is a directional problem in this generation rule, which may cause the problem of too long detection time.
I hope you will actively participate in the discussion.
4. Prevent concurrency.
This rule is mainly for the time setting in the encoding.
5. Control digits.
This is easy to understand. The function of the order number is to facilitate inquiries.
Generally, the normal use scenario should be that when the order is abnormal or returned, the user will report the order number to the customer service, and the customer service will inquire.
Therefore, it is generally better to be in the 10~15 position.
JD.com ranked 10 and Taobao ranked 15.
Several coding rules are recommended:
Year, month, day, hour, minute, second + user ID (you should also pay attention when naming the user ID, do not use a serial number. You can use the area ID + random code + serial number + random code) 1. Uniqueness: time is one-way, to ensure
uniqueness .
2. Security: Just ensure the security of the user ID.
3. The random code does not participate in the judgment, because the previous data has been guaranteed to be non-repetitive.
4. In the same second, the same user will not generate two order codes, so it can prevent concurrency.
5. The number of digits may be within 20 digits, and there are more digits.
Year, month, day, hour, minute, second, microsecond + random code (2) + serial number + random code (3)
1. Uniqueness: Time is one-way, ensuring uniqueness.
2. Security: Just ensure that the serial number will not be recognized.
3. The number of digits and the front and back of the random code are confidential, so if you don't know this, it is difficult to judge the number of digits in the serial number. Because of the large number of orders generated at the same time, the code does not have a linear comparison function. Even if you know the serial number, you can assign it during initialization.
4. In the same second, the same user will not generate two order codes, so it can prevent concurrency.
5. The number of digits may be within 20 digits, and there are more digits.
(The above is from Zhihu@benben)
==============================================
Several common ways of order number:
1. Use the database primary key value to generate a self-increasing order number (the order number is the primary key of the data table)
2. Order number with date + self-increasing number (for example: 2012040110235662)
3. Generate random Order number (65865325365966)
4. Letter + number string format, letters have special meanings, C02356652
Order number design principle: Design
a unique feature code for retrieving order details on demand. You can use the order number to retrieve information such as order date, product category, color, size (or style), and storage space. The order number contains too many The information is a bit "superfluous"! Just design as needed!
User experience rules for order number design:
1. The order number is non-repetitive;
2. If it is convenient for customer service, it is best to use the order number in the form of "date + self-increment number", so that the customer service can know whether the order is within the return guarantee period;
3. Keep the length of the order number as short as possible (within 10 digits), which is convenient for users, especially when making complaints by phone, the probability of error reporting is high for long numbers, which affects the efficiency of customer service
; In the query, the data indexing and retrieval efficiency of the long integer type is much higher than that of the text type, so try to avoid "letter + number string type"!