Кстати, в моей случае, имелась возможность задавать тип поля такой как мне нужно, а не использовать универсальный тип для хранения параметров, хотя в Вашем случае тоже можно запастись несколькими полями с разными типами. Кстати, а как вы выходили из ситуации, если параметр является справочником? У нас такое часто, к примеру для того же параметра диагональ "19", "22", "23" и т.п.? Это все тоже влияет на скорость работы.
В таблице с параметрами есть поле указывающее тип. В таблице со значениями под значения отводятся несколько колонок разного типа: value_int, value_float, value_varchar... и одно поле value тип которого text. Если тип параметра не известен, то пишется в value, т.е. "универсальное" поле, остальное же в null. При известном типе данные пишутся в соответствующую колонку. При этом на value индекса нет, на остальных есть. В целом удобно, особенно когда сначала параметр товара был заведен как, к примеру, целое, в базу записались данные, а потом выяснилось, что оно оказывается дробное. Тогда берем и просто перемещаем из одной колонки в другую.
Параметра справочника быть не может. Потому как справочники должны выделяется в отдельные модули и каталог с ними должен взаимодействовать по API на уровне интерфейсов. Под справочником я понимаю, что-то большее, чем 10-15 записей. Если меньше, то это просто множественные значения параметра, но ни как не справочник. Вообще мне пока такой вариант не нужен, но я бы делал в двух направлениях. В postgresql есть возможность хранить в поле записи массив, соответственно в таблице характеристик заводим поле с именем enum (именно с именем, а не типом, тип у него array) в котором и храним возможные значения. В остальном схема ни как не меняется, если у нас массив с int-ми, то просто пишем в таблицу значений в поле value_int. Если же значений много (к примеру, кода ОКАТО [ибо схема-то применима не только к каталогам товаров, я стараюсь получить нечто большее]) или требуется определенная логика вычисления значения исходя из входных параметров, то получение данных возлагаем на модуль-справочник, в таблице же параметров для данного параметра в поле типов указываем "справочник" и добавляем еще одно поле в котором записаны данные необходимые для вызова справочника.
В общем надеюсь мысль о том, что справочник или перечень возможных значений параметра это не более чем ограничение накладываемое на значения параметра. В таблице значений параметра для конкретного товара у нас все равно уходит
одно значение. Если брать приведенных пример, то двух диагоналей у товара быть не может. Поэтому это ни как не влияет на скорость работы, это влияет на код и структуру таблиц, не более.
