Algorithm 一种生成订单号的好算法
虽然我很喜欢在系统中使用guid作为唯一标识符，但对于订单号等字段，用户可能需要向客户服务代表重复这些信息，这对用户来说不是很友好 生成订单号的好算法是什么Algorithm 一种生成订单号的好算法,algorithm,math,Algorithm,Math,虽然我很喜欢在系统中使用guid作为唯一标识符，但对于订单号等字段，用户可能需要向客户服务代表重复这些信息，这对用户来说不是很友好 生成订单号的好算法是什么 独特的 不连续（仅用于光学） 仅限数值（因此可以通过电话或键盘轻松读取CSR）
- 独特的
- 不连续（仅用于光学）
- 仅限数值（因此可以通过电话或键盘轻松读取CSR）
- <10位
- 可以在中间层中生成，而不需要往返数据库。
仔细审查了每个答案后，我们决定将一个9位数的中间层随机保存到数据库中。在发生冲突的情况下，我们将重新生成一个新的数字。如果中间层无法检查数据库中已经存在的“订单号”，那么它所能做的最好的事情就是生成一个随机数。但是，如果您生成的随机数被限制在10亿以内，那么您应该开始担心大约
sqrt（10亿）不过，这只是一个警告-如果您不小心设置，请查看可能发生的情况。一个解决方案是对订单的某个字段进行哈希运算。这并不能保证它与所有其他订单的订单号是唯一的，但发生冲突的可能性非常低。我可以想象，如果不“往返数据库”，确保订单号是唯一的将是一个挑战
如果您不熟悉散列函数，那么wikipedia页面相当不错 您可以对guid进行base64编码。这将满足除“仅限数值”要求之外的所有标准
实际上，这里正确的做法是让数据库生成订单号。这可能意味着创建的订单模板记录在用户保存之前实际上没有订单号，也可能添加了创建空订单（但可能是未提交的）的功能。对大多数要点的简单回答是： 将前六位数字设置为按顺序递增的字段，并在末尾追加三位哈希值。或者七加二，或者八加一，这取决于您设想必须支持的订单数量
但是，您仍然需要调用后端的函数来保留新的订单号；否则，就不可能保证不冲突，因为数字太少。使用原始多项式作为有限域生成器。OK听起来像是过早优化的经典案例。你可以想象一个性能问题（哦，我的天哪，我必须访问-horror-数据库才能获得订单号！我的天哪，这可能会很慢），结果是一堆错综复杂的psuedo随机生成器和大量重复处理代码
一个简单实用的答案是为每个客户运行一个序列。实际订单号是客户号和订单号的组合。在检索有关客户的其他信息时，您可以轻松检索最后使用的序列 我们没有TTT-CCCC-1A-N1
- T=电路类型（D1E=DS1 EEL、D1U=DS1 UNE等）
- C=6位客户ID
- 1=客户的第一个位置
- A=该位置的第一条电路（A=1、B=2等）
- N=订单类型（N=新，X=断开连接等）
- 1=此电路的此类第一阶
您的竞争对手不会从中获得任何信息，而且很容易实施。您的10位数要求是一个巨大的限制。考虑两阶段方法。
您将对哈希值进行多次点击。但没有那么多。客户服务人员将很容易根据客户提供的其他信息确定有问题的订单。相关：天真的问题：为什么不按顺序？它给你带来了什么？@Mathias-我不想让我们的竞争对手知道我在给定的时间跨度内完成了多少订单。@John-你提到的问题中公认的答案正是我不想做的，那就是依赖数据库打破僵局。@Jason-你为什么不做政府对公民IDSs所做的事情：增加全局计数器，具有随机数量。如果有人感兴趣，这里有一篇关于如何对GUID：+1进行base64编码的文章。对。我们使用按客户顺序的方法。它工作得完美无缺。您需要担心的代码更少。：）@詹姆斯：这并不是说我们害怕访问gasp数据库。这是因为如果您转到数据库并返回中间层以查找下一个逻辑订单号，则可以在分配相同订单号的两个订单之间存在竞争条件。1命令递增并返回结果。电动汽车