Question

一家大型国际公司部署新的网络和MOTO（邮购和电话订购）处理系统。除此之外，您还负责为订单和客户识别号码设计格式。

您认为最好的格式是什么？请列出任何假设和考虑事项。

接受的答案

由于投票率最高，Michael Haren的答案被选中，但请仔细阅读其他答案和评论，因为他们会让Michael的答案更加完整。

Answer 1

使用所有数字或所有字母。如果你必须把它混合起来，那么确保没有含糊不清的字符（Il1m，O0等）。

显示/打印时，每隔3-4个字符放置一个空格，但要确保系统可以处理没有空格的输入。

编辑：要考虑的另一件事是采用内置的方式来区分订单，客户等。客户总是从10开始，订单总是从20开始，供应商总是从30开始等等。

Answer 2

请勿将任意可变客户/订单信息编码到数字中！你必须假设一切都是可变的！

上述一些建议包括区域代码。公司可以搬家。您自己的公司可能会重新组织并更改自己对区域的定义。客户/公司名称也可能发生变化。

客户/订单信息属于客户/订单记录。不在ID中。您可以稍后修改客户/订单记录。身份证通常是一成不变的。

即使只是将生成号码的日期编码到ID中似乎也是安全的，但是假设生成数字的系统上的日期永远不会出错。再次，这属于记录。否则永远无法纠正。

不止一个系统会生成这些数字吗？如果是这样，如果您仅使用基于日期和/或序列号，则可能会出现重复。

在不了解公司的情况下，我会从这条道路开始：

识别号码类型的单字符代码。客户 C ，订单 R （不要使用“O”，因为它可能与零混淆）等。
生成该号码的系统的标识符。该标识符的长度取决于这些系统的数量。
序列号，对于生成它的系统是唯一的。只是一个柜台。
随机数，以防止可猜测的订单/客户编号。只要你的偏执需要，就做这个。
一个简单的校验和。不是出于安全考虑，而是出于错误检查。

将其分解为细分使其更具人性化，正如其他人所指出的那样。

CX5-0000758-82314-12 是此方法生成的可能数字。这包括：

C：这是一个客户编号。
X5：生成号码的电台。
0000758：这是X5生成的第758个数字。在退出此站ID或站本身之前，我们可以生成1000万。或者不要用零填充，并且没有限制。
82314：这是随机生成的，导致1 / 100,000的机会猜测客户ID。
12：校验和。

Answer 3

仅使用数字的主要优点是可以使用10键更有效地输入数据。

该数字的长度应尽可能短，同时仍包含您希望编制的整个实体空间，并留有余地。这可能很棘手，应该考虑一下。在给定一组元素的情况下，一点set theory可以为您提供可以访问的唯一键的数量。

说话时很自然地将数字分成两到四位数。通过以某种模式插入破折号，您可以“强迫”客户以更有效和明确的方式重复它们。

例如，323-23-5344，当然是社会安全号码格式，有助于告知发言者在发出号码时暂停的位置。在编写数字时，它还提供了可视化描述，并且在复制数字时可以轻松进行比较。

我建议订购系统正确屏蔽输入，以便不需要随时输入破折号。这应该通过印刷表格进行，以明确期望应该输入什么。例如，每个数字的打印框用打印的破折号分隔。

我不同意应该在这个数字中嵌入太多的信息，特别是如果这些属性可能会改变的话。例如，假设我们给出“323”这个“很好的顾客”的含义，但他们会以态度四次打电话。我们是否会将他们的客户密钥更改为“324”，“是一个混蛋”？如果他们在04区域并将他们的公司搬到05区域怎么办？

如果发生这种情况，您的选择将是在整个数据库中更新该主键，或者存在嵌入该键中的信息不再可靠的模糊性，从而将所有信息嵌入到可疑实用程序的键中。

最好将可能更改的属性存储为数据库中的单独字段，并使客户编号成为该客户唯一且不变的密钥。

Answer 4

以丹尼尔和迈克尔的问题为基础：如果分开的数字意味着别的东西，那就更好了。例如，我在一家公司工作，账号如下：

XXXXXXXX-XXXXXXXX

第一组数字代表该地区，第二组代表该地区的市场。一旦你习惯了解来自哪些数字，就可以很容易地知道帐户所在的区域，甚至无需查看客户的帐户。

Answer 5

我在回答这个问题时做了几个假设;有些是基于这样一个事实，即它是一个大型的国际组织，有些是基于这种格式适用于两种不同的表类型这一事实。

基于这是一个国际组织这一事实的假设：

每个地区可能需要独立运作 - 也就是说，地区A必须能够独立于地区B添加客户编号
每个地区可能使用不同的语言，以便世界各地的用户可以轻松输入标识符，最好只使用数字和空格。

基于以下事实的假设：将使用此格式：

此格式可能超过列出的两个表使用，因此它应该能够处理任意数量的表。
有经验的用户应该能够根据编码到标识符本身的信息知道他们正在查看的标识符类型。
如果标识符在整个系统中是全局唯一的，那就太好了。

<强>考虑：

对于全球公司，如果仅使用数字，则标识符可能非常长。我们应该尽可能地限制编码到标识符中的无关信息的数量。
标识符应在有限的范围内自我验证;这是一个程序应该能够检测到大部分无效标识符而不需要查找任何内容。这意味着校验和。

建议格式： SSSS0RR0TTC

建议的格式尽可能简单，但并不简单：

C 第一个（最右边）字符将是标识符中所有其他字符的校验和。一个简单的校验和就行了。这将消除所有打字错误的90％。如果确定这还不够，那么这可以扩展到2位数，这将消除所有输入错误的99％。
TT 接下来的N位代表表格类型编号。没有表格类型编号可以包含数字零。
下一个数字是零。此零将表类型编号与区域编号分开。
RR 接下来的N位数是区号。没有区域编号可以包含零。
下一个数字是零。该零将区域与序列号分开。
SSSS 接下来的N位数是序列号。此号码可以包含零。
按照惯例打印或输入时，每组四个数字用空格分隔。在内部它们没有分开，但这有助于用户正确地传输它们。

<强>实施例

假设：
- 客户表类型= 1
- 订单表格类型= 2
- US-Alabama的地区代码= 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 in Ethopia

此方法的优点：

90％的错误号码将被捕获
表格类型数量不限
有无限数量的地区
每个表都有无限数量的连续数字
标识符号对于系统是全局唯一的。这很重要 - 客户编号不能被误认为订单编号，反之亦然。
每个区域可以独立添加没有全局密钥的序列号

<强>缺点

每个标识符至少为六个字符
表格类型数字和地区编号不能包含零，因为零用于将序列号与区域编号与表格类型编号分开。

Answer 6

根据需要设置号码，但不能再使用。每次支付水费时，我都需要输入我的20位客户号码和18位数字发票编号。值得庆幸的是，我的客户编号中的破折号将其分为两部分。
不要依赖于前导零。必须弄明白我的发票号码中有多少个零是非常烦人的。以000000000051415432为例。他们的系统不会只识别51415432。
组合数字。如果你绝对必须使用长数字，那么四位数的块应该可以正常工作。

Answer 7

我从不在ID中使用用户信息。假设您使用客户姓氏的第一个字母，后跟一些数字：例如Thomsom可能是客户THOM-0001。只是，看起来你犯了一个错误，男人的名字是汤姆森而不是汤姆森。用户数据可以更正，ID永远不可修改。所以下次你在TOMS下看Tomson -...你找不到他。与其他数据相同，如客户类型。它总是可以改变，ID不能。
这对RDBMS来说非常基础。

只需使用计数数字。为了便于阅读，最好插入分隔符，使得从不超过4个连续数字：9999-9999优于999-99999。并且不要使数字超过必要的时间;人们因为被减少到20位数而不仅仅被减少到数字而更加恼火。

但是，有一个问题。特别是如果你有一个小企业，简单的柜台可以提供比你所欣赏的更多。说我订购了你的东西，订单号是090145.下个月我再次订购，订单号是090171.呃..一个月26个订单？同样，在一家活跃了10年的企业中成为客户0006我感到不舒服解决方案很简单：跳过数字。不要使用随机数，因为你仍然希望它们按顺序排列。

Answer 8

我的订单号会遵循以下格式：

ddmmyyyy-####-####

#### - ####在每天开始时重置为零。这使得将订单与其下达日期相关联非常容易。

对于客户ID，我会混合使用大写字母和数字，但正如Michael所说，避免使用通常错误的字母（0，o，L，1,5，s）。这将给你30个字符来处理。如果您使用20个字符，那将为您提供几乎64位的客户ID - 非常有利于安全性。确保在生成ID时使用安全随机数生成器。至于如何显示格式，应该如下：

####-####-####-####-####

正如迈克尔再次说的那样，确保你的系统可以处理破折号，空格，没有空格或没有破折号。（它应该在验证之前从输入中删除所有这些字符。）

我希望有所帮助！

Answer 9

您可以添加一个小校验和（例如使用XOR）以确保（增强）给定ID的正确性。如果是通过邮件，请考虑z-base-32编码。但是在这里，通过电话订单，您可能更喜欢小数识别。

Answer 10

假设订单/客户的创建不是集中的，或者不会始终集中，请使用GUID

如果订单/客户的创建始终是集中的，那么无符号整数就可以了

没有令人信服的理由让客户编号的订单号“意味着”任何东西，而且很可能所发明的任何分段编号方案都必须在路上进行彻底改革。坚持一些独特而毫无意义的东西。

编辑：对于MOTO，任何多字符字母标识符都会导致手机出现问题，因此GUID就会出现问题。假设多个分散的MOTO位置，为每个MOTO位置分配前缀（A，B，C等，或01,02，...），并对客户和订单ID使用整数或大整数，例如， 01-1是MOTO位置＃1的第一个订单。请注意，零填充是不必要的，对数字施加隐含的数字限制，并且要求客户在说出数字时区分六个零和七个零。如果您必须使用填充的固定长度格式，请将数字分成不超过4或5位数的组。

ADDENDUM：订单号和客户编号不必是其各自表的主键，只需用于查找的唯一索引列。您可能希望对数据库中的主键使用更简单/更高效的内容。

Answer 11

我们使用前导零作为我工作的一些参考“数字”，我不能告诉你在过去的七年里我浪费了多少时间，迫使Excel将它们视为文本。不要这样做。
自动递增整数对计算机来说都很好，但它们大大降低了人类发现错误的能力。这有多重要取决于您的业务。我使用属性（房屋）相关数据，我们的主要参考是其中嵌入了前门。它并不优雅，但这意味着有经验的管理人员可以在他们靠近数据库之前发现90％的小错误（当我们收到发票等）。但是，在你不依赖于这种过程的环境中，这种说法不那么引人注目。

（现在，有些人强烈警告在引用中使用有意义的数据，因为它可以改变，并且有一些事实，但你可以聪明。你不必选择一些明显变化无常的东西，就像这个人一样结婚了 - 你可以把自己锚定在过去的事件上，比如代表他们第一次开设特定账户的地区的人物。即使你不这样做，也要有某种模式来帮助与客户沟通。我曾经在一个号码上工作过呼叫中心和人们有时会从出生证明开始打电话给每一份文件，因为他们拼命想找到他们的帐户/订单/客户编号。我不认为“这将是1到100万亿之间的数字“会非常方便”

据说，但不要创造极长的参考文献。我们是忙碌的人，我们没有时间通过电话系统键入这个垃圾，并且在数字17上犯了错误只能重新启动（再次）。您的一些客户可能有残疾，而且可能会有超过55岁以上的客户。再次注意零点。您会看到十四位数的采购订单编号等。他们认为他们将要下多少订单？
如果您的网络之外会有任何数据聚合（因此没有连接到您的数据库） - 请使用某种校验位/正则表达式模式，您的合作伙伴/供应商可以验证它们是否已经制作完成错误。其中一个例子就是英国的电力供应编号系统（MPAN）就是一个很好的例子 - 专为人们维护自己的记录而设计而无需下载宇宙中每个电表的大清单来检查它们是否已经制成一个错字。

Answer 12

我会使用数字，因为它是一家国际公司。我会使用空格或破折号每4-6个数字来分隔它。我还会将格式分开以便快速识别

示例：

000-00000-00000 - 可以是客户编号

00000-00000-00000-00000 - 可以是订单号

Answer 13

坚持数字（没有字符或特殊内容）：

可以在IVR流程中轻松输入
它的国际 - 没有语言麻烦
字母与数字没有混淆 - O vs. 0，I vs. 1
只要领先0没有意义，您就可以更有效地存储/操纵它们

Answer 14

我会为订单号和客户编号使用完全数字系统，这样可以避免与其他语言出现问题。

避免使用前导零，因为这会导致数据输入和验证出现问题。

每个数字的位数取决于您的预期音量。您将始终拥有比客户编号更多的订单号。从100000开始的六位数客户编号仍然可以为您提供899,999个客户。为订单号添加额外的3-4位数字，每位客户将获得999至9,999个订单（如果您考虑一个客户，则更多）。

无需在编号序列中构建任何类型的标识。您有其他数据库字段来标识客户来自哪里等。不要过度使系统复杂化。

KISS（保持简单的stackoverflow）

Answer 15

我建议使用16位数字标识符，当打印或显示给客户时，格式为xxxx-xxxx-xxxx-xxxx格式，但存储为系统中没有破折号的数字。

使用这种格式的原因在于，它使人们可以更轻松地将数字读取到手机上进行阅读，因为他们可以分批进行阅读，而不是试图记住他们已经说了多少。

如果您希望前4位数字可用于识别号码类型，1000表示客户，2000表示供应商，3000表示订单，4000表示发票等。

如果您希望使用yymm的格式保留编号在数字本身中的那种信息，那么第二组可以是年/月标识符，因此1000-0903-xxxx-xxxx将是2009年3月输入的客户

然后，这将为您提供实际数据本身的8位数字。

我会考虑在标识符中使用字母对于处理电话的任何系统都是一个非常糟糕的主意，因为重音和理解的差异是如此多样化以至于人们在尝试识别其标识符时会受到不安由一个无法正确理解其口音的人。

Answer 16

这里最大的问题是尽量不要过度思考问题。

虽然我在电子商务系统方面经验丰富，但我认为这篇文章中的一些观点可以应用于邮购和电话订购系统。

对于订单，自动增量整数完全可以作为数据库中的主键以及客户在其发票上看到的数字。绝对没有理由为您的数字创建一些过于复杂的算法。如果您想告诉他们来自哪个国家/地区，请在数据库中使用单独的字段。如果你担心你的竞争对手暗中监视你;让他们！如果您的业务围绕着对您的竞争对手进行间谍活动，因为您没有产生足够的收入，那么很可能您的业务一开始并不好。此外，如果你想欺骗你的竞争对手，你可以创建自己的脚本，自动创建假订单。如果您的电子商务系统设计得很好，那么这不会成为问题。

使用自动增量整数的关键内容：

所有数字/数字=＆gt;更容易沟通，手机上没有含糊之处，适用于使用0-9作为数字系统的所有语言/文化
无需额外编码
在发票上看起来不错，这是客户通过电话拼出的最短数字位数
适用于小型和大型企业
可扩展
Serviceminded / Customerminded（对客户最有利）（se子弹1和3）
简单

无论何时或任何您正在设计的应始终以对客户最有利的方式开始。在一天结束时，他们就是把食物放在桌子上的人。一个满意的客户是回头客。

Answer 17

对我来说，我的首选是获得日期+计数器的组合，用于今天的交易。我被要求只拿出5位数的订单号。因此，我想出以下内容：

我必须得到当前日期
获取当前交易的当前计数器，然后加1。

我决定使用大于十进制的计数（10），所以我使用16进行计数。因此，如果我将从十六进制（FFFFF）获得最多5位数，将是1,048,575计数。通过参与日期，我可以说我每天可以获得1,048,575个计数。因此，为了使该计数每天都是唯一的，我通过得到以下总和来混合日期：

当前年度计算从实施年份开始，即1
当前小时（最多24小时）
一年中的当前日期（最多为365）

因此，我的计数最多会有3个字符。那将是XXX + Todays当前的交易。例如：

当前日期： 2014-12-31 01:22 PM 实施日期：2010年今天的交易总计：100

计数：（5 + 13 + 365）+ 101 = 383101 订货号：AD-5D87D

AD 只有一个自定义订单号前缀。因此，到我执行日期之前，我将失去100万年的订单号。

无论如何，如果您认为每天的交易量可能高达1000000，那么这不是一个好的解决方案。

Answer 18

我总是坚持使用自动增量数字，并且我总是将序列播种得足够高，以便它们都具有一致的数字位数 - 似乎不那么令人困惑。

我有时也会开始一个订单号，比如说6位数字，从200,000开始，5位数的客户号码，从10,000开始，例如，它会给我90,000个唯一的客户号码和800,000个唯一的订单号码，你可以随时使用通过查看它是客户编号还是订单编号来告诉。（即如果客户代表通过电话询问号码，那么很明显哪个是哪个）

然而，我不会在应用程序中构建依赖于此的逻辑，所以即使它确实翻了，系统也不关心。

Answer 19

第一步：在一个足够大的组织中需要这样一个系统，有一个现有的系统正在替换。如果可能，继续以前的系统方案。如果您可以访问旧系统中的数据，即使在基本级别也可以访问它。

也就是说，通常有一个很好的理由来改变这个方案，特别是当它来自遗留系统时。但我发现，在继续之前正式排除旧方案通常会有所帮助。

第二步：这样的系统永远不会存在于真空中。是否已存在用于用户和/或订单ID的组织范围方案，例如会计，库存管理或CRM系统？如果是这样，请考虑采用现有方案以使互操作性更容易。许多大型组织有多种方式来指定单个客户或订单，它只是使得从数据中获取有用的智能更加困难。

第三步：如果旧系统的方案太糟糕而无法继续，并且没有其他方案可以采用，请自行推广。在这种情况下，看看原始方案的缺点，无论它们是什么，并纠正它们。正确的答案取决于申请的具体要求。你给我们的问题陈述太模糊了，无法推测最终形式可能是什么样的。

Answer 20

哇 - 这是一个简单而又有启发性的问题！还有很多矛盾的答案。我认为这里有3个明显的候选答案：

1）使用自动增量长整数。 2）使用GUID 3）使用包含ID中其他信息的复合类型。

对于更简单的系统，尤其是所有用户都在使用中央数据库的基于Web的系统，（1）运行良好。它的优势在于数字尽可能短而简单，但不能缩短，避免使用字母字符（你会惊讶于同一个字母的名称在不同的国家有多么不同 - 一个国家E是另一个国家我）。它本身并不区分订单ID和客户ID，但您可以随时为每个订单ID添加“C”或“O”，并在条目上默默地删除它们？它也没有校验和或错误检查。

对于许多软件组件需要动态创建数字的分布式系统，不需要引用主数据库（2）是唯一的方法。它们具有很大程度上是错误检查的优点，因为地址空间太大，但同样的道理，它太长而且字母数字太大，无法通过电话轻松读取。

至于（3） - 将区域信息或今天的日期嵌入到数字中 - 这些是经验丰富的开发人员训练自己的想法。起初看起来是一个好主意，但总会回来困扰你。考虑客户移动到新状态，或者在最初发布后一周手动重新订购订单的情况？这些信息项属于相关表，在这些表中可以独立编辑它们，ID应仅代表实体身份。重复：永远不要在身份证或主要密钥中编码商业数据 - 每次你这样做，你都会留下一颗定时炸弹让其他人清理一天。

鉴于这是一个集中式（基于电话的）系统，我会选择（1），直到明确需要改变为止。更简单通常更好。如其他人所建议的那样插入连字符，并在必要时添加校验和和/或识别字母。

Answer 21

对代码中格式问题的另一个考虑，为OrderId和CustomerId创建一个单独的类。这些类是不可变的，并验证它们的输入以确保它们是可接受的ID。此外，没有价值可以是订单ID和客户ID。

最简单的方法就是让OrderId的后备值为以1开头的整数，而CustomerIds为以2开头的内联，或类似的东西。

客户编号，订单号的最佳格式是什么？

21 个答案: