数据库中的复合主键

Question

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

我想创建一个"ALERT"表,但很难决定使用哪个主键.我想添加一个至少包含admin_ID(PFK),user_ID(PFK)的复合键,我想在主键上添加日期和时间戳,以指示管理员可以发送许多警报(通知),但只有1某个时间点.
但是,从这个线程:时间戳作为复合主键的一部分？,我了解到我不应该使用时间戳.
顺便说一句,还没有确定我们将在这一点上使用什么数据库软件.

我有时会倾向于快速移动到自动增量键.我从来没有注意到它的问题(在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值冲突.但是,也有办法解决这个问题.当然,自动增量值也没有真正意义.但那没关系.其目的是提供独特性.

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