TarabtsevНадо сделать универсальный механизм, чтобы не зависеть от ТЗ.
Без дополнительных условий это практически невозможно. Ну или сложность использования/внедрения Вашего продукта рискует стать недопустимой.

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

Простые примеры и вопросы, которые должны Вам помочь:
1. Какого типа VALUE в таблице PARAMVALUES? Число (int? float? numeric?), дата, строка, суррогатный ключ к другой таблице? Любой из этих обладает определёнными ограничениями
2. Как быть если для части товаров применимо свойство "срок хранения", для другой части применимо "гарантийный срок эксплуатации", для третьей "вес брутто", для четвёртой "вес нетто" и все эти части пересекаются? Насколько усложнятся запросы, если все эти свойства разнести по разным таблицам?
3. Как быть с цветоразмерным рядом для одежды и обуви? Для каждой модели есть (определённые производителем) допустимые наборы размеров и цветов. Причем черные ботинки размера 40 могут отсутствовать, хотя черные размера 39 и 41 - могут быть. Причем аналитика в отчетах нужна отдельно по цвету, отдельно по размеру. Причем для одного производителя цвет и размер учтены в штрихкоде, для второго не учтены, а у третьего отдельный ШК на каждую партию.
4. Сыр у небольшого оптовика. Он меряется килограммами. Производитель прислал N килограмм. На складе его взвесили. Но фактически сыр лежит круглыми головками и минимальный заказ вашего покупателя 1 головка. Ну вам и заказывают 3 головки. Масса головки 4,5+-0,4 кг. Сколько взять с покупателя предоплаты? Как организовать на складе учет одновременно в головках и килограммах?
5. Предыдущая задача применима и к оптовикам ГСМ. Покупаем тонны, отпускаем литры, списываем тонны. Как организовать пересчет?
6. Если всё хранить в отдельных таблицах, то какие блокировки и как часто будут возникать при эксплуатации системы? Как организовать ввод справочников, чтобы всё время (даже в процессе исправления) были непротиворечивы.

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

Tarabtsevа) б) использовать несколько полей

Если varchar, то как правильно сортировать даты/числа? Если несколько полей, то сразу вырастет сложность обработки, понизится быстродействие, сложнее будет заставить СУБД правильно использовать индексы.
Пример. Построить запрос который для каждой группы товара и вида свойства выведет минимальное значение свойства (под значением свойства подразумевается кортеж <TYPEVALUE, VALUENUMBER, VALUECHAR...>).
TarabtsevЧто характерно для товара, показывает тип товара. Запросы не сильно усложняются, поскольку к "специфическим" параметрам обращаемся не везде, а только там где нужен этот "спецефический" параметр.
Угу. Приведите пример запроса, который выбирает те товары, которые имеют срок хранения 2 недели или более, при этом вес брутто 1 кг или менее или не задан, вес нетто более 0,5 кг.
При этом поясните, как система будет обрабатывать товары для которых разрешено определёное свойство, но нет записи в таблице PARAMVALUES. При этом сравните планы выполнения запросов с тем, когда все значения в одной таблице (особенно при наличии нужного индекса)
TarabtsevЭто проблема не справочника, а проблема учета. Только нужно каждую единицу "цветоразмера" хранить как отдельный товар.
Это не всегда верно.
TarabtsevЭто проблема не справочника, а проблема учета. Всегда будут дебалансы :)
А разве структура системы хранения нормативно-справочной информации не является частью учета? Простейший пример. Некая фирма в своей учетной бухгалтерской программе сделала признак в таблице номенклатуры "Собственный товар"/"Товар на комиссии", т.е. для каждого товара, который был на складе собственный и на комиссии было 2 записи. Стоит описывать к какому бардаку в складском учете это приводило? За счет того что этот признак активно использовался, эту проблему решили только через 10 лет... (Это я об 1С:Бухгалтерии, где эта ошибка прошла из глубины веков до 1С:Бухгалтерии 8)

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

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

Почитайте, как устроено хранение номенклатурной информации в той же 1С:УПП. Возможно, что эта система окажется значительно сложнее, чем Вам нужно, но я встречал случаи, когда она оказывалась слишком примитивной.