Где значение атрибутов "свойства_..." - id записи в соответствующей таблице характеристик. Соответственно, для каждого типа - отдельная таблица с характеристиками. Недостаток - если всего будет N типов, то в сводной таблице у каждой записи будет N-1 неиспользуемых атрибутов.По-моему это самая правильная идея. Единственное, столбцы "свойства_..." не нужны. В качестве первичного ключа во всех таблицах можно использовать id из сводной таблицы. А столбец "тип" можно использовать для определения типа объекта и на его основе рисовать соответствующую форму и джойнить основную таблицу с правильной таблицей свойств.

В принципе, у этого варианта могут быть такие вариации:

1) Вполне возможно, что у разных типов компонентов будут схожие наборы параметров. И можно делать не по одной таблице на каждый тип компонентов, а по одной таблице на каждую группу связанных по смыслу параметров. Например, база магазина бытовой техники: смартфоны, системные блоки, ноутбуки. Наборы параметров могут быть: 1) параметры CPU 2) параметры встроенного GPU 3) параметры дискретного GPU 4) параметры жесткого диска 5) параметры экрана и т.д. У каждого вида объектов может быть свой набор параметров, сгруппированных по смыслу.

2) Можно пойти ещё дальше и нормализовать базу до 6НФ, вынеся каждый атрибут в отдельную таблицу. При этом все атрибуты становятся NOT NULL. Также они все могут стать множественными или историчными при необходимости (например, цена). Упрощается внесение изменений в схему данных: данные в старой структуре лежат как есть, для них не нужно делать никакие миграции, а для новых данных в новой структуре просто добавляем новые таблицы. Такой подход наверное обязателен для хранилищ данных. Для OLTP баз хз, но вроде (я точно не знаю) в том же Avito его используют.