ZdenniZ Надо мне это осмыслить и попробовать в работе! Я правильно понимаю,что в таблице 5 в этом случае будет сборная солянка из кубометров, метров, лошадиных сил, пассажировместимости и т.д.? Сборная солянка будет в таблице 7. По достоинствам недостаткам EAV можно поискать по форуму.
Более скучный традиционный подход - это сделать эти характеристики банальными полями у таблицы "виды оборудования"

ZdenniZ Тут для двух видов огород такой уже нагородился, а если их десять или двадцать? :(То придется городить огород и для десяти/двадцати.
Даже с EAV чудес не будет. Более того, возможно будет легче стартовать, но сложнее поддерживать.

ZdenniZ Ведь в таблице "виды оборудования" - разноплановое оборудование (боны, скиммеры, силовые установки, катера, лодки и т.д.)А как вы с этим работать собираетесь? Как искать, что печатать.
В общем виде - если все это хозяйство реально нужно (вы не ищете катера среди лодок, и не мешаете боны со скиммерами) то
один вид оборудования - одна таблица.
Плюс таблица общий предок
create table devices (device_id int primary key, name varchar, some_common fields)
create table BOOMS (device_id int primary key references devices, some_booms fields)
create table SKIMMERS (device_id int primary key references devices, some_skimmers fileds)
и т.д.

Если же свойства нахрен не нужны - только для печати типа поле description - тогда можете все пихать в одну таблицу

Еще раз повторю если вы реализуете через EAV (таблицы 1-7) - структура базы будет проще (таблиц меньше), но жизнь это вам не облегчит, работать с такой "упрощенной" структурой будет сложнее, поиск будет медленнее в разы.
Сложность вашей модели (со всеми типами оборудования и их характеристиками) она с помощью EAV не убирается - она прячется как страус из словаря СУБД (описания таблиц, полей и связей) в вашу прикладную программу.