Sgt.PepperЯ не являюсь адептом универсальных справочников, но и не согласен с Вашей категоричностью.Никаких обвинений, но мне кажется очевидным, что БД - это не набор произвольных табличек, которые добавляет любой пользователь по своему усмотрению, а система взаимосвязанных сущностей, представляющая некоторую модель предметной области(ПО), которую строит проектировщик.Sgt.PepperДопустим тот случай, когда за классификатором нет никакой бизнес-логики типа: если мужчина, то расчет по одному алгоритму, если женщина - по другому. Скажем, такая классификация будет использоваться исключительно в целях фильтрации набора данных на клиенте. По-моему, возможное допущение.Одним из необходимых признаков "правильно" спроектированной БД является независимость её от приложений, которые пользуются её данными. Т.е., надо отделить мух от котлет, в данном случае, хранение(состояние) данных от их интерпретации. Если вы с этим не согласны, то можно пропустить дальнейший текст абзаца.
Вернёмся к вашему примеру. Если в модели данных классификатор пола никак не связан с другими сущностями, в частности, с персональными данными, то алгоритм никак не поймёт, что тут надо считать так, а здесь эдак. Пока не будет установлена связь, например, между персональными данными и полом, но тогда классификатор пола уже является частью модели данных.
Есть ещё момент, о котором стоит упомянуть, IMHO. В реальной физической БД вполне могут появляться объекты, которые не имеют отношения к модели данных ПО. Хуже того, в ней могут "мирно" сосуществовать несколько разных моделей, что чревато самыми неожиданными проблемами. И это не считая хранения в той же БД данных клиентов(программ), что обычно преступлением не считается, особенно когда есть уверенность, что кроме "нашего" клиента никто с БД не общается. Но, IMHO, надо четко их разделять и не считать, в частности, данные клиента частью модели данных ПО.
Кроме того, современные РСУБД позволяют программировать любую логику с помощью внутреннего языка, как правило, расширением стандарного SQL. Поэтому нередко в БД помимо клиентских данных появляются клиентозависимые алгоритмические объекты, что мне, в общем случае, кажется не совсем правильным, хотя и бывает очень удобным. Мы просто игнорируем тот факт, что эти алгоритмы относятся к интерпретации данных, а не к самим данным и, вообще говоря, не являются частью модели. Не исключаю, что, возможно, вам такой взгляд тоже может показаться слишком радикальным, хотя он практически не отличается от стандартной парадигмы MVC.Sgt.PepperДопустим, что каждую запись можно классифицировать по значительному кол-ву классификаторов, которые часто возникают и исчезают. По мне так тоже вполне жизненная ситуация.
Давайте ограничим возможность классифицировать строку по переменному набору справочников, но так, чтобы было не более одной классификации по одному справочнику. Сможем ограничить раз и навсегда? Думаю - сумеем.
Далее формируется общий суперсправочник. В случае, если каждый классификатор есть отдельная таблица - с использованием метаданных.
Далее формируем n:n таблицу: строка_id, справочник_id, значение_id.
Делаем кнопку "создать новый справочник".
Маша кликает, создает справочник "цвет лака для ногтей", видит его без всяких патчей, классифицирует сотрудниц, фильтрует их на клиенте...Модель данных может изменяться, по тем или иным причинам, с этим спорить вряд ли кто будет. И наличие механизма построения дополнительной семантической сети поверх существующих данных может оказаться полезным, в том числе для дальнейшей эволюции модели, я сам таким занимался. Но это делается простым теговым механизмом и, опять же, не является частью модели, а только интерпретации данных клиентом, до тех пор пока не станет перманентным элементом БД. Или не станет.

Программист-ЛюбительЕсли система большая, выработайте четкую, формальную, однозначную систему именования таблиц и полей. Поиск среди объектов, имена которых подчиняются строгим правилам легко вести автоматически. Если необходимо, дополните (обогатите) словарь БД своей информацией.+1
Хотя подобные правила не менее полезны для системы любого масштаба, так как понятие "большой системы" слишком размыто.