2

当我有以下两张表时，StatusTypes这张表会被认为是矫枉过正吗？即使用它比不使用它有更多好处吗？

在这种情况下，我不希望必须在管理后端加载这些状态来添加或更改/删除它们，但另一方面，我通常不喜欢不使用外键。

我正在寻找支持和反对分离状态类型或将其保留在审计表中的原因。

任何帮助，将不胜感激。

 -- i.e. NEW, SUBMITTED, UPDATED
    CREATE TABLE [dbo].[StatusTypes](
        [ID] [int] IDENTITY(1,1) NOT NULL,
        [Name] [nvarchar](250) NOT NULL,
        CONSTRAINT [PK_StatusTypes] PRIMARY KEY CLUSTERED ([ID] ASC)
    ) ON [PRIMARY]
    GO

    CREATE TABLE [dbo].[Audits](
        [ID] [int] IDENTITY(1,1) NOT NULL,
        [Description] [nvarchar](500) NULL,
        [Country_Fkey] [int] NOT NULL,
        [User_Fkey] [int] NOT NULL,
        [CreatedDate] [date] NOT NULL,
        [LastAmendedDate] [date] NULL,
        [Status_Fkey] [int] NOT NULL,
        CONSTRAINT [PK_Audits] PRIMARY KEY CLUSTERED ([ID] ASC)
    ) ON [PRIMARY]
    GO
4

2 回答 2

1

在这种情况下，我喜欢保留查找表以强制将状态作为一组类型之一。一些数据库有枚举类型，或者可以使用检查约束，但这是 IMO 最便携的方法。

但是，我使查找表只包含一个包含类型名称的字符串列。这样您就不必实际加入查找表，并且您的 ORM（假设您使用一个）可能完全不知道它。

在这种情况下，架构将如下所示：

CREATE TABLE [dbo].[StatusTypes](
    [ID] [nvarchar](250) NOT NULL,
    CONSTRAINT [PK_StatusTypes] PRIMARY KEY CLUSTERED ([ID] ASC)
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[Audits](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    ...
    [Status] [nvarchar](250) NOT NULL,
    CONSTRAINT [PK_Audits] PRIMARY KEY CLUSTERED ([ID] ASC),
    CONSTRAINT [FK_Audit_Status] FOREIGN KEY (Status) REFERENCES StatusTypes(ID)
) ON [PRIMARY]
GO

对特定类型的审计项目的查询将是：

SELECT ...
FROM Audits
WHERE Status = 'ACTIVE'

因此仍然强制执行参照完整性，但查询不需要额外的连接。

于 2012-12-08T21:58:07.570 回答
0

我将提供一个反驳论点：将您的开发时间用在最有用的地方。也许你不需要这个运行时检查那么多。也许您可以将开发时间用于其他更有用的检查。

是否有可能设置无效的状态值？您的应用程序肯定会使用一组常量或枚举，因此不太可能出现一些流氓值。

也就是说，确保完整性有很多价值。我喜欢用一个检查约束来覆盖我所有的“枚举”列，BETWEEN这在运行时可以快速完成，甚至更快。

于 2012-12-08T22:32:28.013 回答