客户号码，订单号码的最佳格式是什么？
一家大型国际公司部署新的networking和MOTO（邮购和电话订单）处理系统。 除其他外，您负责为订单和客户识别号码devise格式。
你认为最好的格式是什么？ 请列出任何假设和考虑。
接受的答案
由于得票最多，迈克尔·哈伦（Michael Haren）的答案被选中，但是当迈克尔的答案更加完整时，请阅读其他答案和评论。
去所有的数字或所有字母。 如果你必须把它混合起来，那么确保没有模棱两可的字符（Il1m，O0等）。
在显示/打印时，请每隔3-4个字符放置一个空格，但要确保您的系统可以处理没有空格的input。
编辑：要考虑的另一件事是build立一个内置的方式来区分订单，客户等，例如客户总是从10开始，订单总是从20开始，供应商总是从30开始等等。
不要将 任何可变的客户/订单信息编码到数字中！ 而且你必须假设一切都是可变的！
上述build议中的一部分包括地区代码。 公司可以移动。 你自己的公司可能会重新组织和改变自己对地区的定义。 客户/公司名称也可以更改。
客户/订单信息属于客户/订单logging。 不在ID中。 您可以稍后修改客户/订单logging。 身份证一般都是用石头写的。
即使只是将编号生成的date编码到ID中看起来也是安全的，但是假定生成该编号的系统上的date永远不会错误。 同样，这属于logging。 否则它永远不会被纠正。
多个系统会产生这些数字吗？ 如果是这样，如果您只使用基于date的和/或连续的数字，则有可能发生重复。
在不了解公司的情况下， 我会开始走下去：
- 用于识别号码types的单字符代码。 C为客户， R为订单（不要使用“O”，因为它可能与零混淆）等。
- 生成该号码的系统的标识符。 这个标识符的长度取决于这些系统中会有多less个。
- 生成它的系统唯一的序列号。 只是一个柜台。
- 一个随机数字，以防止猜测的订单/客户数量。 只要你的偏执狂需要这样做。
- 一个简单的校验和。 不是为了安全，而是为了检查错误。
将其分解成多个部分使其更易于人阅读，正如其他人所指出的那样。
CX5-0000758-82314-12是由此方法生成的可能数字。 这包括：
- C：这是客户号码。
- X5：生成号码的电台。
- 0000758：这是X5生成的第758个数字。 在退出本台ID或本台之前，我们可以产生1000万。 或者不要用零填充，没有限制。
- 82314：这是随机产生的，并导致1 / 100,000的机会猜测客户ID。
- 12：校验和。
仅使用数字的主要优点是可以使用10键更高效地input数字。
该数字的长度应该尽可能短，同时仍然包含您期望编排空间的整个实体空间。 这可能是棘手的，应该给予一点思考。 给定一组元素，一个小集合论可以给你唯一的键的数量，你将有权访问。
将数字分成两至四位数字是很自然的。 通过以某种模式插入破折号，您可以“强制”客户以更高效，更明确的方式重复使用破折号。
例如，323-23-5344当然是社会安全号码格式，有助于通知发言者在发声时暂停何处。 它还提供了编号时的视觉描绘，并且在复制数字时可以很容易地进行比较。
我build议订货系统正确屏蔽input，以免随时input破折号。 这应该通过印刷的forms来提供一个明确的期望，应该input什么。 例如，每个数字用打印的破折号分隔的打印框。
我不同意在这个数字中embedded太多的信息，特别是如果这些属性可能改变的话。 比如说，我们给“323”的意思是“很好的客户”，然后他们四次以一种态度来打电话。 那么我们是否要把他们的客户密钥更改为“324”，“是个混蛋”？ 如果他们在04区域并将他们的公司移到05区域呢？
如果发生这种情况，您的select将是更新整个数据库中的主键，或者生活在embedded该键中的信息不再可靠的含糊之处，从而使所有信息embedded有问题的实用程序的键中。
最好存储可能在数据库中作为单独字段更改的属性，并将客户号码作为该客户唯一的，不变的密钥。
以丹尼尔和迈克尔的问题为基础：如果分开的数字意味着其他的东西更好。 例如，我在一家公司工作，账号是这样的：
XXXXXXXX-XXXXXXXX
第一组数字代表该地区，第二组代表该地区的市场。 一旦你习惯了解什么是数字，那么就可以很容易地知道账户在哪个区域，甚至不需要查看客户的账户。
我在回答这个问题时有几个假设， 有些是基于这样一个事实，即它是一个大型的国际组织，有些基于这样一个事实，即格式是针对两种不同的表格types。
基于它是一个国际组织这一事实的假设：
- 很可能每个地区都需要独立运营 – 也就是说，地区A必须能够独立于地区B添加客户号码
- 每个地区可能使用不同的语言，以使世界各地的用户能够轻松地input标识符，所以最好只使用数字和空格。
假设基于这样一个事实，即有两个表格将被使用：
- 这种格式可能被列出的两个以上的表格使用，所以它应该能够处理任意数量的表格。
- 有经验的用户应该能够基于编码到标识符本身中的信息来知道他们正在查看什么types的标识符。
- 如果标识符在整个系统中是全球唯一的，那将会很好。
注意事项：
- 对于全球性公司来说，如果仅使用数字，标识符可能会很长。 我们应该尽可能地限制编码到标识符中的无关信息的数量。
- 标识符在一定程度上应该是可以自我validation的; 这是一个程序应该能够检测到很大比例的无效标识符而不会查找任何东西。 这意味着一个校验和。
build议格式： SSSS0RR0TTC
提出的格式尽可能简单，但并不简单：
- C第一个（最右边的）字符将是标识符中所有其他字符的校验和。 一个简单的校验就可以了。 这将消除所有打字错误的90％。 如果确定这是不够的，那么可以扩展到2位，这将消除所有打字错误的99％。
- TT接下来的N位代表表格types编号。 没有表types号码可以包含数字零。
- 下一个数字是零。 该零点将表格types号码与区域号码分开。
- RR接下来的N位是地区号码。 没有区域号码可以包含零。
- 下一个数字是零。 这个零将区域从序列号中分离出来。
- SSSS接下来的N位是序列号。 这个数字可以包含零。
- 按照惯例打印或键入时，每组四个数字之间用空格分隔。 在内部他们不分开，但这有助于用户正确地转移他们。
例子
-
假设：
- 客户表格types= 1
- 订单表格types= 2
- 美国阿拉巴马州的地区代码= 1
- CA-Alberta的地区代码= 43
- Ethopia的地区代码= 924
- 10 1013 – 阿拉巴马州客户＃1（3是校验码：1 + 1 + 1）
- 10 1024 – 在阿拉巴马州的＃1
- 9259 0304 3016 – 客户＃925903在加拿大艾伯塔省
- 20 3043 4092 4023 – 订单编号2030434在Ethopia
这种方法的优点：
- 90％的错字会被抓到
- 有不限数量的表格types
- 有数量不限的地区
- 每个表格都有无限制的序号
- 标识符号码是系统全球唯一的。 这非常重要 – 客户编号不能被误认为是订单编号，反之亦然。
- 每个区域可以独立添加序列号，而不需要全局密钥
缺点
- 每个标识符至less有六个字符
- 表格types号码和区域号码不能包含零，因为零用于从表格types号码中区分序号和地区号码。
-
根据需要尽可能长的数字，但不能再。 每次我支付水费时，都必须input20位数的客户编号和18位数的发票编号。 谢天谢地，我的客户号码中有一个短划分，分成两部分。
-
不要依赖前导零。 必须弄清楚我的发票号码中有多less个零是非常烦人的。 以000000000051415432为例。 他们的系统不会仅仅识别51415432。
-
一起组数字 。 如果你确实需要使用长号码，那么四位数字块应该可以正常工作。
我永远不会在ID中使用用户信息。 假设你使用客户的姓氏的第一个字母后跟一些数字：例如Thomsom可能是客户THOM-0001。 只是，看来你犯了一个错误，而这个人的名字是汤臣，而不是汤姆森。 用户数据可以更正，ID永远不可修改。 所以下次你在TOMS下面查汤臣 – 你找不到他。 与其他数据一样，如客户types。 它总是可以改变，ID不能。
这是关系数据库的基础。
只需使用计数号码。 为了可读性，插入分隔符是一个好主意，这样你永远不会有超过4个连续的数字：9999-9999比999-99999更好。 不要让这个数字超过必要的时间; 人们被减less到20位数而不是减less到一个数字更为恼火。
虽然有一个问题。 特别是如果你有一个小企业，简单的柜台可以给你更多的东西，比你会喜欢的。 说我点了你的东西，订单号是090145.下个月我再次订购，订单号是090171.呃..一个月26个订单？ 同样，在一个已经活跃了10年的企业中，我也不愿意成为0006客户。
解决方法很简单：跳过数字。 不要使用随机数，因为你仍然希望他们顺序。
我会让我的订单号码遵循以下格式：
ddmmyyyy-####-#### #### – ####在每天开始时重置为零。 这使得将订单与放置date关联起来非常容易。
对于客户ID，我会混合使用大写字母和数字，但正如Michael所说，避免常见的错误字母（0，o，L，1,5，s）。 这会给你30个字符来处理。 如果您使用20个字符，那么您将获得几乎64位的客户ID范围，这对于安全性来说非常有用。 确保在生成ID时使用安全的随机数生成器。 至于你如何显示格式，应该是这样的：
####-####-####-####-####
正如迈克尔再次说，确保你的系统可以处理破折号，空格，没有空格，或没有破折号。 （它应该在validation之前从input中去掉所有这些字符。）
我希望有帮助！
您可以添加一个小的校验和（例如使用XOR）以确保（增强）给定ID的正确性。 如果是邮件，请考虑z-base-32编码。 但在这里，通过电话订购，您可能更喜欢小数点标识。
假设订单/客户的创build不是集中的，或者不总是集中的，则使用GUID
如果订单/客户的创build将始终是集中的，则无符号整数就可以
客户号码的订单号码没有任何意义上的“意思”，任何发明的分段号码scheme都有可能被彻底改变。 坚持一些独特而无意义的东西。
编辑：对于MOTO，任何多字母字母标识符都会在手机上引起问题，所以GUID是正确的。 假定多个分散的MOTO位置，为每个MOTO位置分配一个前缀（A，B，C等，或01,02，…），并使用整数或大整数作为客户和订单ID，例如01-1是MOTO第一个地点的第一个订单。 请注意，零填充是不必要的，对数字施加了隐式的数字限制，并且要求客户在说出数字时区分六个零和七个零。 如果您必须使用填充的固定长度格式，请将数字分成不超过4或5位的组。
附录：订单号和客户编号不必是各自表的主键，只是用于查找的唯一索引列。 你可能会想为数据库中的主键使用更简单/更高效的方法。
我只会使用数字，因为它是一家国际公司。 我会使用空格或破折号每4-6个数字来分开它。 为了快速识别，我也将格式分开
例：
000-00000-00000 – 可能是客户号码
00000-00000-00000-00000 – 可能是订单号码
坚持数字（没有字符或特殊的东西）：
- 可以在IVRstream程中轻松input
- 它的国际 – 没有语言障碍
- 字符与数字没有混淆 – O对0，I对1
- 只要前导0没有意义，就可以更有效地存储/操作它们
-
我们使用领先的零来代表我们工作的一些参考“数字”，我不能告诉你在过去的七年里我浪费了多less时间来迫使Excel将它们当作文本对待。 不要这样做。
-
自动递增整数对于计算机来说都非常好，但它们大大减less了人类发现错误的能力。 这是多么重要将取决于您的业务。 我与财产（房屋）相关的数据工作，我们的主要参考有embedded式的前门。 这并不高雅，但这意味着有经验的pipe理人员可以在他们靠近数据库之前发现90％的小错误（当我们拿到发票等时）。 但在不依赖于这种过程的环境中，这种说法不那么引人注目。
（现在有些人强烈警告说，在参考文献中使用有意义的数据是可以改变的，这里有一些事实，但是你可以很聪明，你不必挑选一些明显变幻无常的东西，你可以将自己固定在过去的事件上，比如说他们首先开设一个特定账户的地区的angular色，即使你不这样做，也会有一些帮助与客户沟通的模式，我曾经在一些呼叫中心人们有时会拿着出生证上的每一份文件来打电话，因为他们拼命想find自己的账号/订单/客户号码，我不认为“这个数字在1到100万亿之间”非常便利）
-
有人说，但不要创造很长的参考。 我们很忙，我们没有时间通过电话系统键入这个垃圾，只是在数字17上犯了一个错误，只能重新启动（再次）。 您的某些客户可能有残疾，而且越来越多的客户可能会超过55岁以上。 再次注意零点。 您可以看到十四位数字的采购订单号码等。 他们认为他们将要放置多less个订单？
-
如果networking之外有任何数据聚合（因此没有连接到您的数据库） – 请使用某种forms的校验码/正则expression式模式，您的合作伙伴/供应商可以validation他们没有犯错误。 其中一个例子是英国的电力供应编号系统（MPAN）就是一个很好的例子 – 专为人们维护他们自己的logging而devise，而不必下载宇宙中每个电表的大名单来检查他们没有做的一个错字。
我将使用一个完全数字系统的订单号和客户号码，这将允许您避免与其他语言的问题。
避免前导零，因为这会导致数据input和validation问题。
每个数字的数字将取决于您的预期音量。 您将始终拥有比客户编号更多的订单编号。 一个六位数的客户号码从100000开始仍然会给你899,999个客户。 为订单号码增加3-4位数字，每个客户将会给你999到9,999个订单（如果你考虑一个客户的话，订单数量会更多）。
没有必要在您的编号顺序中build立任何types的标识。 你有其他的数据库字段来识别客户来自哪里，等等。不要让你的系统过于复杂。
KISS（保持简单的计算器）
我build议使用16位数字标识符，当打印或显示给客户的格式为xxxx-xxxx-xxxx-xxxx格式但存储为系统中没有破折号的数字。
使用这种格式的原因是，它使得人们更容易读出电话号码，因为他们可以批量地读取数字，而不是试图记住他们已经说了多less。
如果您希望可以使用前4位数字来标识号码types，客户1000，供应商2000，订单3000，发票4000等。
如果您希望保留这种编号的信息，使用yymm格式，那么第二组可以是年/月标识符，所以1000-0903-xxxx-xxxx将是2009年3月进入的客户。
然后这会为您留下8位数字来表示实际的数据本身。
我认为在标识符中使用字母对于处理电话的任何系统来说都是一个非常糟糕的主意，因为口音和理解的差异是如此的多样化以至于人们在试图让他们的标识符被人无法正确理解自己的口音。
在代码中对格式问题的额外考虑，为OrderId和CustomerId创build一个单独的类。 这些类是不可变的，并validation它们的input以确保它们是可接受的ID。 此外，没有价值可以和订单ID和客户ID。
最简单的方法就是让OrderId的后备值是以1开始的整数，而CustomerIds是以2开始的整数，或类似的东西。
哇 – 多么简单但是揭示性的问题！ 还有很多矛盾的答案。 我认为这里有三个明显的候选答案：
1）使用自动增长长整数。 2）使用GUID 3）使用包含ID中其他信息的复合types。
对于更简单的系统，尤其是所有用户正在访问中央数据库的基于Web的系统，（1）运行良好。 它的优点是数字尽可能简短，但不能短，避免字母字符（你会惊讶地发现同一个字母在不同国家的名称是不同的 – 一个国家E是另一个国家I）。 它本身并不区分订单ID和客户ID，但是您可以始终预先添加或附加“C”或“O”，并在input时默默放置它们？ 它也没有校验和或错误检查。
对于许多软件组件需要dynamic创build数字的分布式系统，无需参考主数据库（2）是唯一的方法。 它们的优点是很大程度上检查错误，因为地址空间非常大，但是同样的道理，太长和字母数字以便在电话上舒适地阅读。
至于（3） – 将区域信息或今天的dateembedded数字 – 那些经验丰富的开发人员将自己排除在外的各种想法。 起初看起来是一个好主意，但总是回来困扰着你。 考虑客户移动到新的状态，还是在最初签发一周后手动重新生成订单的情况？ 这些信息属于相关的表格，在这些表格中，它们可以独立编辑，只能代表实体标识。 重复一遍：不要在ID或主键上编码业务数据 – 每次你这样做的时候，你都要给别人留下一个定时炸弹来清理一天。
鉴于这是一个集中（基于电话）系统，我会select（1），直到有明确的需要改变。 简单通常更好。 如其他人所build议的那样插入连字符，并根据需要预先安排或附加校验和和/或标识字母。
第一步：在一个组织足够大，需要这样一个系统，有一个现有的系统，你正在取代。 如有可能，继续以前的系统scheme。 如果您可以访问旧系统的数据（即使在基本级别），也可以使许多事情变得更加简单。
也就是说，改变scheme通常有很好的理由，特别是当它来自遗留系统时。 但是，我发现，在继续之前正式排除旧计划通常是有帮助的。
第二步：像这样的系统永远不存在于真空中。 用户和/或订单ID是否已经存在组织范围的计划，如会计，库存pipe理或CRM系统？ 如果是这样，考虑采用现有的scheme，使互操作性更容易。 许多大型组织可以通过多种方式来指定一个客户或订单，而只是从数据中获得有用的智能。
第三步：如果旧系统的scheme太糟糕了，没有其他scheme可以采用，请自行打印。 在这种情况下，不pipe它们是什么，看看原来的scheme的缺点，然后纠正它们。 正确的答案将取决于应用程序的具体要求。 你给我们的问题陈述太模糊，无法有效推测最终forms的样子。
我总是坚持使用自动递增数字，而且我总是将序列sorting得足够高，以便它们都具有一致的数字位数 – 似乎不那么令人困惑。
我也有时候会开始一个订单号码，比如说6位数字，从20万开始，客户号码是5位数字，从10,000开始，例如可以给我90,000个唯一的客户号码和800,000个独特的订单号码供您使用，看它是否是客户号码或订单号码。 （也就是说，如果客户代表通过电话询问一个号码，那么哪一个会立即明显）
然而，我不会在应用程序中build立依赖于它的逻辑，所以即使它翻过来，系统也不会在意。
这里最大的问题是尽量不要过问这个问题。
虽然我在电子商务系统方面更有经验，但我认为这篇文章中的一些观点可以应用于邮购和电话订购系统。
对于订单，自动递增整数完美地作为数据库中的主键以及客户在他/她的发票上看到的数字。 绝对没有理由为你的数字创build一些过于复杂的algorithm。 如果您想知道他们来自哪个国家/地区，请在数据库中使用单独的字段。 另外如果你担心你的竞争对手在监视你; 让他们！ 如果您的业务是围绕着竞争对手进行的，因为您没有获得足够的收入，那么最有可能您的业务部门首先就不好。 另外，如果你想欺骗你的竞争对手，你可以创build自己的脚本，自动创build伪造的订单。 如果你的电子商务系统devise得很好，那么这不会是一个问题。
关键的东西使用自动增量整数：
- 所有的数字/数字=>更容易沟通，通过电话没有歧义，适用于所有使用0-9作为数字系统的语言/文化
- 没有额外的编码
- 在发票上看起来不错，这是客户通过电话可能需要的最短的数字
- 适用于小型和大型企业
- 它是可扩展的
- Serviceminded / Customerminded（对客户最好）（第一和第三项）
- 简单
无论什么时候或者你正在devise什么，都应该始于对客户最好的东西。 在一天结束时，他们把食物放在你的桌子上。 一个快乐的客户是一个回头客。
对我而言，我的首选是获得date+今天交易柜台的组合。 我被挑战拿出只有5位数的订单号码。 所以，我拿出以下几点：
- 我必须得到当前的date
- 得到今天交易的当前柜台然后加1。
我决定使用大于十进制（10）的计数，所以我使用16进制计数。 所以，如果我将得到hex（FFFFF）的最大5位数，将是1,048,575计数。 通过涉及date，我可以说我每天可以得到1,048,575个计数。 所以为了让这个数字每天都是独一无二的，我通过得到以下总和来混合date：
- 本年度从实施年份开始计算1
- 当前小时（最大24）
- 今年的当天（最多365天）
所以，我将有一个最多3个字符开始计数。 那么这将是XXX +今天的当前交易。 例：
当前date：2014-12-31 01:22 PM实施date：2010年今天交易总额：100
计数：（5 + 13 + 365）+ 101 = 383101订单号：AD-5D87D
AD只有一个自定义的订单号码前缀。 所以到我执行date为止100万年的时间里，
无论如何，如果你认为你每天的交易量可能高达1000000，那么这不是一个好的解决scheme。
