复合主键

Question

我这里有一个小场景，我认为使用复合主键是一个很好的解决方案。我在 SSMS 中这样做。下面是创建表的代码：

CREATE TABLE [PSDesk].[dbo].[Local](
    [UserID] [varchar](10) NOT NULL,
    [FullName] [varchar](50) NOT NULL,
    [ComputerName] [varchar](15) NOT NULL,
    [IPAddress] [varchar](50) NOT NULL,
    [NETFramework] [varchar](50) NOT NULL,
    [ComputerModel] [varchar](50) NOT NULL,
    [UDrive] [varchar](50) NOT NULL,
    primary key (UserID, ComputerName)
)

我希望UserID和ComputerName列是唯一的，这意味着 UserID 和 ComputerName 的每个组合只有一个记录。这是获得我正在寻找的解决方案的好方法吗？我没有太多经验，所以我只是在寻找建议，我只是使用我的 google-fu 把它放在一起

Answer 1

那个语法正确吗？是的。您还可以在之后使用一些不同的语法选项创建 PK，但这会构建。

但是这个问题有很多答案。这个问题有很多问题。“这是一个好主意吗？” 嗯，这取决于——这是基于意见和情况的，所以如果没有用更具体的问题稍微缩小一点，这个问题就可以结束了。

当您将某物定义为主键时，您是在说明这是描述一行且仅描述一行的事实或事实集。

因此，对于该表的外观，仅从数据库设计的角度来看，UserID 和 ComputerName 的组合似乎就足够了。

不过还有其他问题。问题不在问题中，而是诸如：

1. 为什么 UserID 作为 varchar ？为什么不是指向 User(s) 表的 INT？这可能是一个更合适的范式。
2. ComputerName 也一样。
3. 该表的用途是什么 - 似乎它描述了一台计算机。为什么在那里有用户信息？为什么没有用户表和计算机表，然后是将用户分配给计算机的表？（不是说一种方式更正确，只是一个问题。）
4. SQL Server 在创建主键时的默认行为是在通过 GUI 执行时使表上的索引聚集 - 这还不错，但我喜欢较窄的聚集索引和聚集索引，它们单调增加并且不太可能有索引碎片和页面拆分。出于这个原因，我往往更倾向于“复合聚集索引”阵营。有时这意味着我组成了一个 PK 并让它像 ComputerUserID 一样聚集起来——并且让它成为一个身份列。有时我只是将其用作集群，并在您尝试时仍然使用自然键作为主键。
5. 如果您创建了一个代理键作为该表的 PK 并作为聚集索引，您仍然可以在 ComputerName 和 UserID 的组合上创建一个唯一索引并强制执行唯一性。

只是一些思考的食物。这个问题可能有很多答案。这就是为什么我不能 100% 确定它会持续，但至少现在有一些想法。