Question

Q: Is there any way to implement self-documenting enumerations in “standard SQL”?

   EXAMPLE:
   Column: PlayMode
   Legal values: 0=Quiet, 1=League Practice, 2=League Play, 3=Open Play, 4=Cross Play

What I’ve always done is just define the field as “char(1)” or “int”, and define the mnemonic (“league practice”) as a comment in the code.

Any BETTER suggestions?

I’d definitely prefer using standard SQL, so database type (mySql, MSSQL, Oracle, etc) should’t matter. I’d also prefer using any application language (C, C#, Java, etc), so programming language shouldn’t matter, either.

Thank you VERY much in advance!

PS:
It’s my understanding that using a second table – to map a code to a description, for example “table playmodes (char(1) id, varchar(10) name)” – is very expensive. Is this necessarily correct?

Answer 1

The normal way is to use a static lookup table, sometimes called a “domain table” (because its purpose is to restrict the domain of a column variable.)

It’s up to you to keep the underlying values of any enums or the like in sync with the values in the database (you might write a code generator to generates the enum from the domain table that gets invoked when the something in the domain table gets changed.)

Here’s an example:

--
-- the domain table
--
create table dbo.play_mode
(
  id          int         not null primary key clustered ,
  description varchar(32) not null unique nonclustered   ,
)

insert dbo.play_mode values ( 0 , "Quiet"          )
insert dbo.play_mode values ( 1 , "LeaguePractice" )
insert dbo.play_mode values ( 2 , "LeaguePlay"     )
insert dbo.play_mode values ( 3 , "OpenPlay"       )
insert dbo.play_mode values ( 4 , "CrossPlay"      )

--
-- A table referencing the domain table. The column playmode_id is constrained to
-- on of the values contained in the domain table playmode.
--
create table dbo.game
(
  id          int not null primary key clustered ,
  team1_id    int not null foreign key references dbo.team(      id ) ,
  team2_id    int not null foreign key references dbo.team(      id ) ,
  playmode_id int not null foreign key references dbo.play_mode( id ) ,
)
go

Some people for reasons of “economy” might suggest using a single catch-all table for all such code, but in my experience, that ultimately leads to confusion. Best practice is a single small table for each set of discrete values.