是否需要序号？

Question

我正在开发一个winform(.NET)应用程序,其中包括订单,发票,服务订单,票务等.

在为ID编号时,这些enities是否必须是顺序的？IMO没有.例如,接受订单,它只有在通过业务层后才有效,在该过程中,另一个订单可能已经创建,批准并保存为数字2,而之前创建的ID为1的订单未通过验证.

这似乎打开了一堆蠕虫关于哪一层分配订单号,不是吗？

目前我正在使用前缀为实体标识符的非序列号.例如,订单使用OR-123.这是一个好主意吗？

谢谢

有关:

SQL Server中数据库范围内唯一且简单的标识符

Answer 1

如果它是有效的业务需求,您只需要具有顺序ID.

Answer 2

顺序数字不是必需的,在某些情况下是一个坏主意(在安全意识的系统中,猜测是一个问题).但是让RDBMS处理这个问题是相对常见的 - 大多数支持IDENTITY自动递增类型(尽管它对于多个分布式主服务器变得更复杂).另一种选择Guid当然是重复的可能性很小.

前缀方法对于快速识别数字非常方便 - 但您可以选择在数据库上方的层前面添加"OR-".

Answer 3

根据我在美国使用现成和定制会计系统的经验，会计师或审计师不需要序列号。所需要的是控制和审计能力的展示。如果某个项目被删除，则必须有一个痕迹。删除项目的检测不会通过丢失的号码来跟踪 - 毕竟，还有其他类型的篡改可以绕过需要序列号的情况，并且充分控制的演示远远超出了这一范围。

不过，我在墨西哥看到过这样的要求，要求政府报销。我相信他们用它来避免向国家机构多次提交材料的欺诈行为。IMO，这不是有效的内部控制，并且在第三方交互情况下捕获欺诈的范围有限。

一般来说，使用递增的整数 id（如 IDENTITY）（或 GUID - 但正常的 GUID 不会像这样递增）作为表中的代理主键并进行集群，这有​​助于提高 SQL Server 性能。请注意，IDENTITY 值可能会被用完，但事务可能会失败或回滚，从而留下间隙。该间隙通常不会被填补（尽管可以通过使用身份插入来填补）。

以下是一些 COMB ID 链接：

http://jeffreypalermo.com/blog/use-guid-comb-in-your-database-if-you-need-guid-keys-but-don-t-want-to-take-a-big-performance-打/

http://www.informit.com/articles/article.aspx?p=25862

我们实际上对其进行了一些修改，将它们与 CSLA 一起使用，并将它们称为 SmartGUID。SmartGUID 类公开了创建日期属性。不幸的是，我不再隶属于该项目或公司，因此我无法访问源代码来准确回忆我们的技术。