2

以下の 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

この状況では、ルックアップ テーブルを保持して、ステータスが一連のタイプの 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 に答える