Тык смотрите выше...
Посмотрел... и... увидел...
Да, всё хорошо, но
- Неудобная/непривычная запись (мелочь);
- Неполное описание атрибутов (серьёзно).
Чтобы дополнить атрибуты/характеристики, то должны быть...
- тип характеристики (числовой: целый, вещественный; строковый; дата_время... множественный(?))
- единицы измерений характеристики ('шт.', 'г', 'л', 'г/м3', и пр.)
- перевод ед. измерения (в другой таблице... но надо)
- обязательность характеристики (nullable)
... а в некоторых случаях и этого мало, и нужна ссылка на регламентирующий данный узел документ (ISO, ГОСТ, ОСТ, ТУ).
Недостатком является и то, что значения (в таблице значений) должны хранится в строковом виде, а, следовательно, к ним напрямую неприменимы операторы SQL... вроде MAX, MIN, AVG и т.д. По той же причине значения не могут быть ссылками...
А поскольку в пользовательской таблице (описание атрибутов/характерисстик) фактически дублируется информация из системных таблиц (тип, обязательность), то это я и назвал "ассемблером".
Но такой вариант (с указанными выше ограничениями/замечаниями) является вполне себе рабочим... Его недостаток только в том, что таблица значений будет громоздкой... Например, если в среднем один узел описывается 10 характеристиками, до для 1 000 000 объектов этого узла, будем иметь 10 000 000 значений характеристик. Для современных СУБД - это не те объёмы, чтобы говорить о "тормозах"...
PS. Если из таблицы характеристик, убрать суррогатный ключ, то и таблица станет... проще, и естественный ключ <название характеристики> мигрирует в таблицу значений, сделав её более осмысленной и удобной... исключив лишний JOIN из запросов на выборку.