复合主键

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？为什么不使用一个指向用户(S)表的INT呢？这将是一种可能更恰当的正常形式。
2. ComputerName也一样。
3. 这张表的目的是什么--就像它描述了一台计算机。为什么有用户信息在里面呢？为什么不拥有一个用户表和一个计算机表，然后是一个分配用户给计算机的表呢？(不是说一条路更正确，只是一个问题。)
4. 在创建主键时，SQL Server的默认行为是在通过GUI时将表上的索引聚集在一起--这还不错，但我喜欢比较窄的聚集索引和聚集索引，它们单调增加，不太可能出现索引碎片和分页现象。因此，我更倾向于在“综合聚集指数”阵营中。有时，这意味着我要组成一个PK，让它像ComputerUserID一样聚集起来，并将其作为一个身份列。有时，我只是使用它作为集群，并且在您尝试时仍然使用自然键作为主键。
5. 如果您创建了一个代理键作为此表的PK，并且是聚集索引，则仍然可以在ComputerName和UserID组合上创建唯一索引，并强制执行唯一性。

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

Answer 2

这不是第三范式。

如果两个或多个用户共享一台计算机，那么您将拥有计算机的重复条目。如果没有共享，那么您可以只使用计算机名。

应该为用户和计算机提供单独的表。然后是第三个交接台。

Answer 3

是否可以更容易地将表分成两个表:一个用于用户，另一个用于计算机。然后，您可以同时在PK和FK上建立您的关系模式！据我所知，主键的独特之处在于阻止一对一的关系。此外，为什么用户ID和计算机名称有相同的数据类型的varchar？