SQL Server 2005 中主键的 smalldatetime vs int - “假期”表答案

【问题标题】：smalldatetime vs int for Primary Key in SQL Server 2005 - 'Holidays' tableSQL Server 2005 中主键的 smalldatetime vs int - “假期”表
【发布时间】：2013-12-27 15:26:43
【问题描述】：

我必须在 SQL Server 2005 数据库中创建一个新表 "holidays"。

第一个选项：

ID Int **PK**
CustomerId nvarchar (10)
HolidayDate Smalldatetime
Description nvarchar (50)

第二个选项：

CustomerId nvarchar (10) **PK**
HolidayDate Smalldatetime **PK**
Description nvarchar (50)

我认为通常我只需要在 HolidayDate 和 CustomerId 上加入一些查询。

我会更专注于后者，因为我会少一个字段，而且它在我看来“逻辑上”更好，即使我不得不担心不会插入重复记录。

你怎么看？

皮莱吉

【问题讨论】：

使用第一个选项将允许您将该 ID 用作另一个表中的外键。
是的，但通常我只需要在 HoidayDate 和 CustomeId 上加入一些查询...
即使您使用代理键，也没有什么能阻止您在 {CustomerID, HolidyDate} 上创建唯一键。但这里有一些我想考虑的问题。 CustomerID 和 holidayDate 是如何填充的？如果有错误会发生什么？ CustomerID 和 HolidayDate 是否可以更新？
如果您将来有几个宗教的假期日期重叠怎么办？
关于是否使用代理或自然主键有一场古老的宗教战争（我在代理阵营），虽然没有强制执行，但我认为最好至少与您所做的选择保持一致。换句话说，其他表是否使用代理键？如果是这样，我会在这里做同样的事情。

标签： sql sql-server tsql primary-key composite-primary-key

【解决方案1】：

传统的数据库设计（强烈）建议您的 PK 应该是一个在 DB 中有意义的值（一个 Int、自动编号或类似的东西），而不是对用户有意义的东西（例如日期），因为有意义的值往往导致 PK 冲突和尴尬的验证逻辑。如果您坚持推荐/经典的方法，事情就会简单得多。

有时，复杂的密钥似乎是一种更好的方法，但您通常不会获得太多收益。但是，您通常会产生复杂性。

所以，坚持使用选项 1，并可能应用索引来表示选项 2 而不是 PK。

【讨论】：

谢谢大家，也很抱歉对我的问题投了反对票的人，也许我的问题很无聊而且没用，对于某人来说，幸运的是不是所有人，在这个论坛上都有相同的意见......

【解决方案2】：

您需要使用 int 键。原因很简单。假期不限于一个日期。光明节有好几天。斋月长达一个月。因此，即使在您的第一个答案中，您也需要更新架构以具有开始日期和结束日期

【讨论】：