Каков наилучший способ самостоятельного документирования «кодов» в приложении на основе SQL?

Question

В: Есть ли способ реализовать самодокументируемые перечисления в «стандартном SQL»?

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

То, что я всегда делал, это просто определяю поле как "char (1)" или "int", и определяем мнемонику ("практику лиги") как комментарий в коде.

Есть ли ЛУЧШИЕ предложения?

Я бы определенно предпочел использовать стандартный SQL, поэтому тип базы данных (mySql, MSSQL, Oracle и т. Д.) Не должен иметь значения. Я также предпочел бы использовать любой язык приложений (C, C #, Java и т. Д.), Поэтому язык программирования также не должен иметь значения.

Спасибо ОЧЕНЬ большое заранее!

PS: Насколько я понимаю, использование второй таблицы - для сопоставления кода с описанием, например, «таблица режимов воспроизведения (char (1) id, varchar (10) name)» - очень дорого. Это обязательно правильно?

Answer 1

Обычным способом является использование статической таблицы поиска, которую иногда называют «доменной таблицей» (поскольку ее целью является ограничение домена переменной столбца.)

Вы должны поддерживать базовые значения любых перечислений и т.п. в синхронизации со значениями в базе данных (вы можете написать генератор кода для генерации перечисления из таблицы домена, которая вызывается, когда что-то в домене таблица меняется.)

Вот пример:

--
-- 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

Некоторые люди по соображениям «экономии» могут предложить использовать единую универсальную таблицу для всего такого кода, но, по моему опыту, это в конечном итоге приводит к путанице. Лучшая практика - это отдельная маленькая таблица для каждого набора дискретных значений.

Answer 2

добавить внешний ключ в таблицу «коды».

таблица кодов будет иметь PK как значение кода, добавьте столбец описания строки, в который вы вводите описание значения.

table: PlayModes

Columns: PlayMode     number  --primary key
         Description  string

Я не могу видеть это как very expensive, базы данных основаны на соединении таблиц, подобных этой.

Answer 3

Я согласен с @Nicholas Carey (+1): таблица статических данных с двумя столбцами, например, «Ключ» или «ID» и «Описание», с ограничениями внешнего ключа для всех таблиц, использующих коды. Часто столбцы идентификаторов представляют собой простые суррогатные ключи (1, 2, 3 и т. Д., Значения которых не имеют значения), но когда это целесообразно, я иду дальше и использую «специальные» коды. Ниже приведены несколько примеров.

Если значения являются последовательностью (скажем, Упорядоченный, Платный, Обработанный, Отправленный), я мог бы использовать 1, 2, 3, 4, чтобы указать последовательность. Это может упростить задачу, если вы хотите найти все «до конца» этапы предоставления, такие как все заказы, которые еще не были отправлены (ID <4). Если вы планируете заранее, сделайте их 10, 20, 30, 40; это позволит вам добавлять значения «между» существующими значениями, если / когда появляются новые коды или статусы. (Да, вы не можете и не должны пытаться предвидеть все и все, что, возможно, придется сделать когда-нибудь, но такая предварительная планировка может сделать некоторые изменения намного проще.) </p>

Ключи / идентификаторы часто являются целыми числами (1 байт, 2 байта, 4 байта, что угодно). Есть небольшая стоимость, чтобы сделать их символьными значениями (1 символ, 2 символа, 3 символа, 4 символа). Это символ , а не переменный символ . Сделав это, вы можете использовать мнемонику в своих кодах, например

• O, P, R, S
• Или, Pd, Pr, Sh
• Ordr, Платный, Проц, Корабль

... или что-то еще, что плывет на вашей лодке. Сделано так, я обнаружил, что это может сэкономить много времени при анализе или отладке. Вам все еще нужна таблица поиска для целостности отношений, а также напоминание для более неясных кодов.

Answer 4

Эта информация должна быть где-то в базе данных, а не в комментариях.

Итак, у вас должна быть таблица, содержащая эти коды, и к ней в таблице должен быть FK.