正确使用带有时间戳的数据的主键答案

【问题标题】：Correct usage of primary key with timestamped data正确使用带有时间戳的数据的主键
【发布时间】：2012-01-06 00:21:36
【问题描述】：

我有一个表，它存储来自一组传感器的带时间戳的记录，这些读数每天被采集 14400 次。（每 6 秒）。

有 4 个传感器，它们共享它们的主数据表。

目前架构如下：

id (int-PK)
time (DateTime)
sensor (int)
reading (int)

这很好用，我将主键设置为自动增量。

然而，拥有这个主键似乎很愚蠢，因为我从不引用它 - 使用时间和传感器的组合作为复合键会更好吗？

如果我确实使用了复合键，我假设我每行的字节数也会减少吗？这是相关的，因为该表超过 10m 行，因此任何节省都是值得的。

这似乎是双赢的，但我想看看这种方法会产生什么影响。

【问题讨论】：

它是什么类型的数据库？（例如，它是 Oracle、SQL Server 吗？）
MSSQL 2008 R2，虽然我看不出我的问题太针对技术了？
除了将日期时间放入 PK 之外，我从来没有遇到过任何问题。当您的插入因重复而开始失败时，您会希望自己没有这样做。
在这种情况下，插入重复数据失败将是我的预期行为。
只是检查您的数据库引擎是否对日期时间和组合主键有任何限制。

标签： c# sql-server database

【解决方案1】：

应避免使用复合索引，尤其是复合主键。索引更宽，这对性能（和内存使用）不利。在我个人看来，拥有复合主键也是糟糕的设计，因为没有更多独特的单一方式来引用您的行。

我的建议是坚持你现在的设计。

【讨论】：

我有一个基于传感器和时间戳（都是 ASC）的聚集索引，你是说这也是个坏主意吗？
关于索引大小的要点。我认为既然他没有以任何方式使用PK作为外键参考，那么这没有什么区别。但如果空间是问题，那么这是有道理的。

【解决方案2】：

此时您使用的是surrogate key。而且您正在评估是否转移到natural keys。

与自然键相比，使用代理键具有优势，您可以在上一个链接中了解：

不变性
要求更改
性能
兼容性
一致性

（来自维基百科）

您可以在 stackoverflow 中查找有关 surrogate v.s. natural keys 的其他帖子。

但每个设计都与其他设计不同。作为数据库分析师，您应该评估什么是最适合您的项目的决策。

【讨论】：

【解决方案3】：

坚持设计，除了将日期时间放入 PK 之外，我从来没有遇到过任何问题。当您的插入因重复而开始失败时，您会希望自己没有这样做。

如果您想节省空间，请为 sensor 列添加一个小整数（您只有 4 个不同的值）。 reading 可能更小一些，我怀疑传感器可以记录 int 可以存储的 2 万亿个不同的值，很可能您可以使用 smallint 或 tiny int。

bigint   8 bytes, -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807
int      4 Bytes              -2,147,483,648 to             2,147,483,647
smallint 2 Bytes                     -32,768 to                    32,767
tinyint  1 byte                            0 to                       255

【讨论】：

您提出了一个有效的观点，我的传感器和读取列的开销可能会小得多。作为一个快速的问题，回想起来在我的数据库上更改它会导致我丢失数据吗？
如果您的所有值都适合新的数据类型，那么您不会有任何问题。您需要查看您的聚集索引和填充因子/填充，以查看列减少是否只会增加每页的空白空间。如果您不确定我在说什么，请提出一个新问题（包括来自 SSMS 的原始表和聚集索引创建脚本以及您打算运行的 alter 命令）

【解决方案4】：

在 10M 行上使用组合主键（或唯一索引）很容易耗尽通过删除 int PK（以及更多）获得的任何存储空间。此外，从该表中引用一行将变得更加困难。

我总是在任何表上保留一个 int（或 bigint，如果需要）PK。与其余数据相比，存储空间通常相对较小，并且始终可以轻松地链接/引用行，这使得 WRT 对数据模型的增强和更改变得更加容易。

【讨论】：