数据库中的复合主键

Question

我需要创建一个数据库设计，其中bar或事件所有者（admin-table因为他们拥有配置文件）向用户发送警报。

我想创建一个“ALERT”表，但很难决定使用哪个主键。 我想添加一个至少包含admin_ID（PFK），user_ID（PFK）的复合键，我想在主键上添加日期和时间戳，以指示管理员可以发送许多警报（通知），但只有1某个时间点。
但是，从这个帖子：Timestamp as part of composite primary key?，我了解到我不应该使用时间戳 顺便说一句，还没有确定我们将在这一点上使用什么数据库软件。

我有时会倾向于快速移动到自动增量键。我从来没有注意到这个问题（在Access中），但是根据我的阅读，这可能并不总是最有意义的事情，因此我向专业人士提出这个问题。
我只有一次机会以正确的方式做到这一点，使后端基本正确 你对此有何看法？

Answer 1

对于PK用什么问题，你会得到很多热烈的争论。纯粹主义者会告诉你，你永远不应该使用自动增量键（假设是SQL SERVER）。在真正的战壕中的人会告诉你他们作为PK（在大多数情况下）完全没问题，并且具有一些真正的优势。

我不会试图以某种方式说服你。但我会告诉你我的经历。我已经开发了25年的软件，并且大部分时间都在使用RDBMS（主要是SQL Server）。就个人而言，我发现自动增量PK非常宝贵，99.99％的时间永远不会考虑使用其他任何东西。为什么呢？

1. SQL Server生成它们，因此处理所有并发问题。
2. 它们的尺寸很小，因此，对这些键的查找速度非常快。
3. 您可以通过其Id值轻松引用表中的特定行。这可能听起来不是什么大不了的事，但它肯定会派上用场。例如，我不能告诉你有多少次我要求一位合作开发人员看一下表格中的一行，键值为12345.这很简单，但非常有用。
4. 在表中引用PK的FK将是相同的类型，因此也小而快，并且易于使用。
5. 索引很少或没有碎片，特别是如果PK是聚簇索引（在SQL Server中）。

这种PK可能有一个很大的缺点。如果您必须将行从一个数据库合并到另一个数据库，则可能会遇到PK值冲突。但是，也有办法解决这个问题。当然，自动增量值也没有真正意义。但那没关系。其目的是提供独特性。

这是一个完美的解决方案吗？不。而其他人则不同意它们的使用。但是，对于大多数高端和关键业务项目而言，它们对我来说非常有效。

Answer 2

您始终可以选择使用UUID（http://en.wikipedia.org/wiki/Universally_unique_identifier）作为数据库主键。

所有主要的编程语言都支持它和IMO它是一种选择，可能虽然不是最好的，因为它的效率很低。

Answer 3

• 复合主键本身
没有任何问题
• 如果PK的任何组件都是NULLable，则会出现问题
• ...例如当任何组件也作为另一个表（或“域”）的FK运行时