Жёсткие справочники. На клиенте или на сервере? Ваш опыт.

[Alex03]

Т.е. имеется некий статус у записи, выраженный небольшим количеством значений. Количество и назначение этих значений не меняется (хотя......).
Клиенты непосредственно работающие с этим полем используют соответствующие константы, поэтому им по сути справочники не нужны. С другой стороны другие приложения могут не знать про значения этого поля, но могут хотеть его отображать (типа генераторов отчётов), и тут полезен справочник вида "значение - строка".

Вопрос:
Про Вашему опыту от какого количества значений становится полезен справочник? Или прям от 2-х?

[kdv]

я когда то использовал жесткие значения. при этом справочник в виде таблицы был, для гарантий ссылочной целостности. но проверки шли по явным значениям.
см. пример в
www.ibase.ru/devinfo/treedb2.htm
это про таблицу "набор прав". на модельках ее нет, но она существовала.

[CyberMax]

Если речь идет о состоянии записи, то, имхо, справочники здесь не нужны. Дело в том, что таблиц с такими записями может быть неопределенное количество и соответственно, у них будет неопределенное количество наборов состояний. А под каждую таблицу создавать такую дополнительную таблицу с состояниями - накладно. Проще обойтись просто проверкой значения состояния, чтобы она не выходила за диапазон допустимых границ. А в отчетах использовать уже преобразование числа в слово. Если число состояний будет изменено, скорее всего все равно придется переписывать отчеты.

[Dimitry Sibiryakov]

Дык, "справочники" здесь и не нужны, достаточно одного, универсального. У меня, например, на все расшифровки была всего одна таблица, хранящая все сразу.

Код: Выделить всё

Create table ClassContent
( Link LinkField Constraint ClassContPrimary primary key,
  Class LinkField Constraint ClassName references ClassNames (Link),
  Code VarChar(15) default '' not null,
  Name VarChar(254) not null Constraint EmptyClassName Check (Name<>''));