使用时间戳加整数作为主键

Question

在 Sql Server 中，使用主键的缺点和缺点是：

两个字符表标识符 + YEAR + MONTH + DAY + HOUR + MINUTE + MILLISECOND + 0 到 100 之间的随机整数？

为什么这比使用 Integer Auto_Incremented 字段更受欢迎？（除非它不会，那我也想知道。）

我很想知道为什么这是一个非常糟糕的设计实践。为了取回该整数值而强制转换所有内容也是一件非常痛苦的事情。

我基本上有机会让我的小开发团队访问以帮助改进我们的应用程序数据库，这是非常需要的 - 避免像主键 Varchar(50) 字段左填充零这样的情况，或者只是开始改进非- 规范化的数据库，或一个字段中的逗号分隔列表。

Answer 1

你当然可以做到，但你为什么要这样做？保存几个 CAST 表达式？那好像有点弱。

使用自动递增代理 int PK 的原因有很多：

1. 您几乎不需要使用普通数据库来管理它们。曾经。除非您正在重建表或插入数据，否则您必须关闭和打开标识。但在操作上它运行良好，开销很小。如果您按照建议的方式进行操作，则需要使用 UDF 来创建密钥，这会导致更多的开销，这比自动增量 int 需要更多的 CPU 周期来创建。

2. 它们是最有效的存储解决方案。您建议的方式需要 varchar(20)/char(20) 左右，这意味着每行 20 个字节仅用于键。一个普通的 int 只有 4 个字节。它可能看起来并不多，但在其中放入 1 亿行，大小就会增加大约 1.5GB。不酷。然后你必须把它作为 FK 放在另一个表中，另一个 1.5GB。或者在其他 3 个表中，您的数据库不必要地大了近 5GB。你明白了...

3. 表格应该真正与用户不关心或不理解的东西联系在一起。这使您作为 DBA 的控制粒度较低，您可以参考该值，用户对此一无所知，当进行高度粒度的更改、微调表或管理数据结构时，这变得很重要。我可以根据使用具有您建议的复合键的数据库的经验告诉您这一点。它们变得令人沮丧地烦人，您总是很想放入一个自动递增的 int 并解决复杂性和挫败感。例如，想象一下，您希望快速插入一大堆来自不同来源的记录。使用自动增量，轻松减少对服务器资源的影响。使用复合键...您必须运行一个 UDF，它为每个插入创建键。.. 并且在您的示例中，每毫秒 100 个密钥的随机化器可能还不够，SQL Server 可能对您来说工作得太快，并为您提供 2 条记录的相同 ID。该死，您需要一种不违反唯一约束的不同方法。或者想象一下，用户出于某种原因希望开始“重用”一个密钥（它发生了，有时是出于“回收使数据库更快”的一些错误想法）。用户最终试图自己调整数据库，这是灾难的秘诀。在幕后告诉他们（并让他们知道）发生的事情，他们不理解会提供一定程度的分离，通常可以避免这种情况。他们不会尝试优化任何事情，而是将他们的小手指从您的业务中抽出来，这意味着您可以优化它应该完成的方式。

4. SQL Server 期望 int PK-FK 自动增量并为此进行了优化。由于插入记录时的 FK 检查，这意味着整体处理速度更快。

   整数之间的比较通常很快，这对于 joins也是如此。引擎中有很多针对 integer/bigint 的优化（太多无法列出），但作为一个例子，向下搜索 b 树可能会使用线性插值而不是二分搜索。作为第二个例子，当归一化表示适合 64 位时，批处理模式处理要快得多。这适用于 integer 和 bigint，但不适用于 UUID 等。第三个示例，基于非空整数/bigint 构建的位图过滤器可以推送到存储引擎中以进行早期评估。当不超过 64 位阈值时，位图过滤器在批处理模式下也可以更有效。

5. 最后，我发现自然键对于几乎不需要优化和管理的用户很少的小型数据库来说绝对没问题。当查询很简单时，它们还可以使查询看起来更清晰（通过在 WHERE 语句中使用复合键），这意味着您的联接表较少等。但是一旦数据库开始变得越来越大和复杂......管理自动递增的整数代理键变得容易多了。

我的最后一个想法：复合键对于成员数量较少（意味着复合键较短，因此空间要求较低）且不会发生大量变化（意味着低管理开销）的查找表很好。一个例子是美国的两个字母的州代码。它们可能意味着可能会减少一个连接和多个存储过程，这可能会带来很小但可衡量的性能改进。

Answer 2

这绝对不会比自动递增整数字段更好。

对于初学者：

1. 根据您的建议，索引宽度将显着降低。
2. 您建议如何管理所有这些随机的 2 位整数以强制唯一性。您是否想过需要编写和维护多少代码才能实现此方案。
3. 为实现中的每个连接输入所有这些关键字段不会是一种乐趣。

作为旁白; 到底为什么要在这个新字段的每个实例中插入两个字符的表标识符？从正在检查的表中可以立即明显看出该行所形成的表。

如果您确实认为大量站点之间的数据冲突率如此之高，以至于足以证明此类方案的合理性，那么至少使用 GUID（一项已经实现的技术），而不是这种 NIH 设计。

更新

自动增量键的单调性质在一些非常有效的统计表算法中用于运行总计（至少） ，以强制运行总计计算的正确排序。该方案将使这些算法的使用无效。