我正在开发一个winform（.NET）应用程序，其中包括订单，发票，服务订单，票务等。
在为ID编号时，这些enities是否必须是顺序的？ IMO没有。例如，接受订单，它只有在通过业务层后才有效，在该过程中，另一个订单可能已经创建，批准并保存为数字2，而之前创建的ID为1的订单未通过验证。
这似乎打开了一堆蠕虫关于哪个层分配订单号，不是吗？
目前我正在使用前缀为实体标识符的非序列号。例如，订单使用OR-123。这是个好主意吗？
由于
答案 0 :(得分：7)
如果它是有效的业务需求，您只需要有顺序ID。
答案 1 :(得分：5)
序列号不是必需的，在某些情况下是一个坏主意（在安全意识的系统中，猜测是一个问题）。但是让RDBMS处理这个问题是相对常见的 - 大多数支持IDENTITY自动递增类型（尽管它对于多个分布式主服务器来说变得更加复杂）。另一种选择当然是Guid - 重复的可能性很小。
前缀方法对于快速识别数字非常方便 - 但您可以选择在数据库上方的层前面添加“OR-”。
答案 2 :(得分：4)
会计和总帐人员喜欢序列号，如果数字丢失，他们想知道原因。这是一种会计实践，如果不遵守规范可能会花费业务时间和金钱。
答案 3 :(得分：4)
我认为我们应该在技术ID和我们可以称之为文档ID之间做出改变。可能会出现法律要求。例如，在瑞典，我认为法律要求您的发票按照不间断的顺序发票。
但是，如果我要设计一个发票系统，我可能会选择一个与发票ID分开的技术ID，最好没有任何逻辑（例如Guid）。
答案 4 :(得分：3)
根据我在美国现有和定制会计系统的经验，会计师或审计师不需要序号。所需要的是控制和审计能力的演示。如果删除了某个项目，则必须有一个跟踪。删除项目的检测不会被缺失的数字跟踪 - 毕竟，还有其他类型的篡改需要序列号，并且充分控制的演示远远超出了这一点。
但是，我在墨西哥看到了这种要求政府偿还的要求。我相信他们使用它来避免多次提交给州政府机构的欺诈行为。国际海事组织，它不是一个有效的内部控制，在第三方互动情况下捕捉欺诈的范围有限。
通常，使用递增的整数id（如IDENTITY）（或GUID - 但正常的GUID不会像这样增加）作为表中的代理主键并在其上进行群集有助于提高SQL Server性能。请注意，IDENTITY值可能会用完，但事务会失败或被回滚，从而留下空白。这个差距通常不会被填补（尽管可能是通过使用身份插入）。
以下是一些COMB ID链接：
http://www.informit.com/articles/article.aspx?p=25862
我们实际上对它进行了一些修改，将它们与CSLA一起使用并称之为SmartGUID。 SmartGUID类公开了创建日期属性。不幸的是，我不再隶属于该项目或公司，因此我无法访问源代码以完全回忆我们的技术。
答案 5 :(得分：2)
将使用该应用程序的国家/地区的会计规则可能需要发票上的序号。
您可能会习惯用户根据序号进行思考。也许员工会下注谁打包订单号10000？如果有人告诉他们赌注已经关闭，他们可能会非常沮丧，因为有了新的计算机系统。
答案 6 :(得分：2)
如果相关字段是您的主键，即使您从1跳到3等，插入的序号也会更快。
但序号确实会引入安全问题：人们“猜测”网址，意外转换数字或泄露商业数据（您拥有多少用户等）。
一种选择是使用GUID（uniqueidentifier类型）。对于大声说话或打字而言，这不是人类友好的，但它足够随机和独特。
如果您使用的是SQL Server 2005，则新的SequentialID（）函数将返回一个顺序GUID，它为您提供所需的唯一性，并快速插入表中。
如果您选择使用某种随机数字，我建议您在表格中使用smalldatetime列默认为GETDATE（），这样您就可以按创建日期对行进行排序和过滤。
答案 7 :(得分：0)
你应该问你的业务联系人，数字是否真的真的需要顺序，而不是我们。
并告诉同一个商人，在大多数情况下，对于计算机系统而言，对此提供水密保证是不可能的。