title: When is a SQL Server foreign key table too much?
body: <p>When I have the below two tables, would the <code>StatusTypes</code> table be considered as overkill? i.e. is there more benefit to using it than not? </p>
  
  <p>In this situation I don't expect to have to load these statuses up in an admin backend in order to add or change/ delete them, but on the other hand I don't often like not using foreign keys.</p>
  
  <p>I'm looking for reasons for and against separating out the status type or keeping it in the Audit table. </p>
  
  <p>Any help would be appreciated.</p>
  
  <pre><code> -- 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
  </code></pre>