我需要创建一个数据库设计，酒吧或事件所有者(管理员表，因为他们拥有个人资料)向用户发送警报。
我想创建一个“ALERT”表，但很难决定使用哪个主键。
我想添加一个至少包含 admin_ID (PFK)、user_ID (PFK) 的复合键，并且我想将日期和时间戳添加到主键以指示管理员可以发送许多警报(通知)，但只有 1 个在某个时间点。
然而，从这个线程:Timestamp as part of composite primary key? ，我了解到我不应该使用时间戳。
顺便说一句，目前还没有决定我们将使用什么数据库软件。
有时我倾向于快速移动到自动增量键。我从来没有注意到这方面的问题(在 Access 中)，但是从我读到的内容来看，这可能并不总是最有意义的事情，因此我向专业人士提出这个问题。
我只有一次机会以正确的方式使后端从根本上正确。
你对此有何看法？
最佳答案
关于使用什么进行 PK 的问题将会引起很多激烈的争论。纯粹主义者会告诉您永远不要使用自动递增键(假设是 SQL SERVER)。身处实战的人会告诉你，他们作为 PK 非常好(在大多数情况下)并且有一些真正的优势。
我不会尝试以任何方式说服您。但我会告诉你我的经历。我从事软件开发已有 25 年，大部分时间都在使用 RDBMS(主要是 SQL Server)。就个人而言，我发现自动增量 PK 非常宝贵，99.99% 的时间永远不会考虑使用其他任何东西。为什么？
- SQL Server 生成它们并因此处理所有并发问题。
- 它们的尺寸很小，因此查找这些键的速度非常快。
- 您可以轻松地通过其 ID 值引用表中的特定行。这听起来可能没什么大不了的，但肯定可以派上用场。例如，我已经记不清有多少次我要求合作开发人员查看表中键值为 12345 的一行。这很简单，但非常有用。
- 在表中引用 PK 的 FK 将是同一类型，因此也小而快，并且易于使用。
- 索引很少或没有碎片，尤其是当 PK 是聚集索引(在 SQL Server 中)时。
这种 PK 可能有一个很大的缺点。如果您必须将行从一个数据库合并到另一个数据库，则可能会遇到 PK 值冲突。但是，也有一些方法可以解决这个问题。当然，自动增量值也没有真正的意义。但没关系。其目的是提供唯一性。
这是一个完美的解决方案吗？没有。其他人会不同意使用它们。但是，对于大多数高端和业务关键型项目，它们对我来说效果很好。
关于database - 数据库中的复合主键，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12387695/