Home/ Questions/Q 1087965
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T23:00:35+00:00

Maybe i’m going about this wrong but my working on a database design for

  • 0

Maybe i’m going about this wrong but my working on a database design for one of my projects.

I have an entity with a classification column which groups up entities into convenient categories for the user. These classifications are predefined and unchangeable by the user (at least thats the current design).

I’m trying to decide if I should have a ‘EntityClassification’ table which contains simply an ‘Id’ column as the primary key with no other information in order to have an enforced relationship between the Entity:Classification -> EntityClassification:Id.

I don’t plan to have a name/description column in EntityClassification since my current thought is that I’ll need to support localization of these pre-defined names which will be done with static string table like resource files downloaded to the client based on their country/language. There really isn’t any other data which is associated with this EntityClassfication that I would want and a table seems like it might be an overkill?

Is this common/recommend practice for this type of problem? We’re using SQL Server 2008 and don’t have an enum datatype for the database which would seem to be really what i’m trying to achieve.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Do you just want to ensure that the values in Entity:Classification are restricted to your pre-determined list? If so a check constraint might be what you need.

    Such constraints aren’t as flexible as foreign keys: to alter the checked values we have to drop and recreate the constraint, but then you say there are no plans to change the values so that shouldn’t matter.

    • 0