数据库设计首选项：在 SQL 2000 中使用 DateTime 和 BIT

Question

我需要通过示例来解释这一点：

是否有在数据库表中指定日期时间和位的最佳实践或首选项？

在我的数据库中，我有一个小部件表。我需要知道小部件是否“已关闭”及其“关闭日期”业务规则规定，如果小部件已关闭，则它必须有一个关闭日期。如果小部件未关闭，则它不应具有“关闭日期”。

为了设计这个，我可以执行以下操作：（

示例 1）：

CREATE TABLE [Widget]
(
    [WidgetID] INT IDENTITY(1,1)
    ,[ClosedDate] DATETIME NULL
)

或（示例 2）：

CREATE TABLE [Widget]
(
    [WidgetID] INT IDENTITY(1,1)
    ,[IsClosed] BIT NOT NULL CONSTRAINT [DF_Widget_IsClosed] DEFAULT (0)
    ,[ClosedDate] DATETIME NULL
)

我认为示例 1 更清晰，因为它少了一个需要担心的列。但是，每当我需要评估小部件是否已关闭时，我都需要一个额外的步骤来确定 ClosedDate 列是否不为空。

示例 2 会产生额外的开销，因为现在我必须保持 IsClosed 和 ClosedDate 值同步。

设计这样的东西时有最佳实践吗？ 对于示例 2，查询表的性能是否会更高？我有什么理由应该选择一种设计而不是另一种设计？

注意：我将通过 ORM 工具以及存储过程访问该值。

Answer 1

我认为选项 1 更好。数据完整性得到更好的保持（不可能有一个带有相反标记的关闭日期），在超大表的情况下占用更少的磁盘空间，并且查询仍然是高性能的并且对于队友来说是清晰易懂的。

Answer 2

第一个更好。检查空值的成本很低，而保留单独的标志则可以有一个关闭日期但尚未关闭。

Answer 3

我认为您将 IsClosed 列作为计算列。

CREATE TABLE [Widget](    
[WidgetID] INT IDENTITY(1,1),
[ClosedDate] DATETIME NULL,
IsClosed AS CAST(CASE WHEN ClosedDate IS NULL THEN 0 ELSE 1 END AS BIT)
)

原因是您没有存储任何内容，现在可以编写应用程序代码和存储过程来使用此列。如果您的业务规则发生变化，您可以将其转换为真正的列，而无需更改其他代码。否则，您的应用程序代码和存储过程中将会散布业务逻辑。这样，它就只在 1 个地方。

最后，当您迁移到 SQL2005 时，您可以添加“Persisted”子句。因此，它将被存储，从而稍微提高性能，并且保持它们同步不会有问题。

Answer 4

我不会将语义赋予 NULL。这样做会在您的业务逻辑中冒泡，您将得到类似的代码...

public class Widget
{
  // stuff

  public bool IsClosed
  {
    // what do you put here?
    // it was null in the db so you have to use DateTime.MinDate or some such.
    return( _closeDate == ?? );  
  }

  // more stuff
}

以这种方式使用 null 是不好的。 NULL（和 null）意味着“我不知道”。您正在为该答案赋予语义，而实际上您不应该这样做。关闭状态就是关闭状态，关闭日期就是关闭日期，不要合并。 （例如，上帝禁止您想要重新打开小部件，但仍然记得它最初关闭的时间。）

Eric Lippert 有一个 关于以这种方式使用 null (kidna) 的不错的博客文章。