В_поисках_1Друзья, нужна помощь в понимании концепции.

Начну сразу с примера. В какой-либо организации заводим информацию сотрудниках. Информация стандартная: ФИО, адрес, паспортные данные, образование, воинская обязанность и т.д.
Некоторые из этих полей свободны для ввода значений (ФИО, адрес), другие же имеет смысл делать списком (предоставлять выбор значений). Например, образование у нас имеет фиксированные и повторяющиеся значения, воинские звания, годность - аналогично. Соответственно возникает вопрос о создании справочников, таких как: "Вид образования", "Воинское звание", "Годность к службе".

В общем, вопрос состоит в том, насколько корректно использование множества справочников, структура которых примитивна: 2 поля (ID и текстовое описание)?
Множество это, разумеется, может быть приличным по объему. Вше я привел лишь несколько примеров.

Дело в том, что руководитель считает использование подобных справочников бессмысленно. Однако альтернатив никаких не подсказывает.

Откройте секрет, пожалуйста :)
Благодарю!
Любое "поле" связано с понятием "классификатора". Когда Вы введете в поле "Фамилия" значение "Петров" - Вы отнесете человека к классу людей, имеющих фамилию Петров. Аналогично по любому другому полю (формально - абсолютно по любому). Ваш руководитель, концептуально, прав - раз Вы не заводите справочник по Фамилии, почему его необходимо заводить по другим полям? Аргумент - ограниченное число значений - не является убедительным. Как провести границу? Несколько более убедительным (но тоже не достаточно) является аргумент, что два атрибута: код и наименование.
В СУБД для таких случаев используется специальный тип свойства. Который как раз и отличается тем, что его значение состоит из двух атрибутов. Разумеется, можно так же использовать и стандартное решение с отдельными таблицами и "ключами". Поскольку СУБД в Вашем распоряжении просто нет именно его Вам и нужно использовать))

lLocustВ_поисках_1,

Использование справочников всегда оправдано, когда используются связи pk-fk.
Но можно немного извернуться. Создается таблица с id_справочника, id значения, значение. (т.е. одна таблица на множество справочников)
Изворачиваться не нужно. Так как возникнут другие проблемы (например, поддержка ОЦ), то есть, Вы будете вовлечены в цепочку изворачиваний))

spLSV1. Ну у программиста должны быть "тиражные решения". Иначе он всю жизнь будет боянить в каждой системе одни и те же справочники.
2. При наличии универсального справочника+ EAV, заказчик может сам создать новый справочник и тут же его заюзать.

Любая долгоживущая система (с уклоном в доработки время от времени) должна иметь подобный механизм. Тогда большая часть доработок будет настройками не меняя исх.код. И сама система и ее настройки смогут легко переноситься с одной системы в другую.

А при чем тут ЕАВ?? В тиражной системе должен быть интерфейс создания сущностей, связей, ограничений и всего прочего!!
ЕАВ действительно ну жен в очень редких условиях и когда нужно чтоб быстро, но в реальных больших системах ЕАВ просто зло - быстро в начале - задница в конце!
Не в тиражной системе, а в СУБД. Иначе это не СУБД))