"订单"表的身份增量有什么好的价值？ (如购物车订单中的订单)

我希望显示订单号，以便我们拥有比实际更多的订单，并且在可能出现问题的情况下，使用户更难猜测其他用户的订单号。

我不想太大的值，以至于我可能用完了所有的值，而且我也不想出现明显的序列。

我现在已经定居42

解决方案

向最终用户公开ID通常不是一个好主意(安全性)。

我将使用常规的+1自动递增ID列，并将用户可见的订单号作为基于当前日期的字符串。也许使用日期+到目前为止的订单数量：" 20080919336"。

我要说的最重要的是让身份种子开始时像156,786之类的东西。至于增量，最好使用奇数，这样并非所有订购号都是偶数。

但是，我必须说，最好不要对要向用户公开的订单使用"身份"字段。通常最好将这些内容隐藏在数据库中，并在订单号中使用单独的字段。这样，我们可以在不弄乱所有参考文献的情况下更改订单号。我们所有其他表都将引用"标识"字段(应作为主键)，然后我们可以在另一个"订单"字段上打一个索引以使其保持唯一。

待会儿我会谢谢你的。

我们可以使用非数字的订单参考代码，例如" ABC0123"。取决于平台，但是我们既可以将其用作表的主键，也可以将其用作自动递增的标识符(然后将其简单地用作内部引用)。

另外：如果用户猜测订单号是一个问题，那么我们确实需要考虑一些安全措施。

为什么要增加？使用GUID将使订单数量难以猜测，并且几乎不可能猜测订单URL(显然，我们仍要检查查看该订单的人是否有权查看它)。

如果确定要使用单调递增的整数ID，则只能估算出用完多少订单。但是，如果有人可以看到其中的少数几个并猜出序列号，它们总是很容易被猜到的。然后，他们会知道我们确切地有多少个订单，并且能够整天猜测URL。

我们可以使用indenity值。只需将种子高高，然后将其捏碎即可。

[ID] [int] IDENTITY(5497,73) NOT NULL,

我有一种感觉，如果人们看到他们是1号订单，他们将不在乎。我要做的是将其设置为3百万，增量为1. 这将是一个很大的数目，并且会上升。如果我们认为人们不购买是因为他们是要订购的第五个人，那么我们可以随时重新设置种子。

尽管这是所有问题的答案，但42不是一个好选择。

一种可能是我们使用客户ID和添加的增量编号...，但是在这种情况下，这不会是在订单表上带有种子的"身份增量"。

示例：JoeBlow在客户表中的ID为56，这是他的第18个订单(5618)
并进一步掩盖订单计数(？)，我们可以按照自己喜欢的方式进行其他操作，添加毫秒/随机数或者类似的内容。这是一个简单的例子

如果要使其显示的订单数量超过实际数量，只需选择一个任意大的id编号即可。但是，如果是我，我就将增量设置为1. 为防止用户猜测订单号，对数字进行混淆可能不是最好的选择。

如果我是用户123，并且下了一个订单，编号为4567，那么假设查看该订单的网址如下所示：

http://example.com/orders?id=4567

假设我感觉调皮，决定开始使用该网址。如果我尝试：

http://example.com/orders?id=5000

如果还没有订单5000，它将显示什么？像"无效的订单ID"这样简单的事情怎么办。但是，然后说我尝试：

http://example.com/orders?id=4568

那个订单确实存在，它应该显示订单吗？它可以检查创建订单的用户的ID，除非是我(老用户＃123)，否则显示相同的错误消息"无效的订单ID"。除非用户自己创建了订单，否则这将使用户无法判断是否存在任何给定的订单ID。

为什么不拥有一个随机数池，然后从池中取出下一个随机数？这可以通过获取一些数据(用户ID和计数器)并使用一些加密/哈希算法来完成。

• 创建一个递增的Int作为内部PK。为存储和索引性能提供出色的填充因子。
• 创建一个散列，复合键或者GUID作为外部AK-此值应该是在窗体等上公开的值。美国驾驶执照号是人为组合键的一个很好的例子-由唯一的随机数加上驱动程序的任意组合生成名称字符。
• 从来没有将GUID作为聚集索引-这会导致可怕的页面填充问题