Имеет ли смысл разбивать значения свойств товаров по разным таблицам?

Честно говоря предложенное вами решение касательно

сделать таблицу Entity|Attribute|Value_str|Value_int|Value_boolean

выглядит уж очень странным.

Вы говорите что подход EAV не очень, есть предложения какой подход использовать вместо него?

Максим Зайцев, имхо, любой EAV - "странный":). Этот вариант ничуть не лучше и не хуже любого другого EAV. В нём будет меньше соединений с таблицами свойств, чем в варианте с разными таблицами, но нужно будет реализовывать больше логики при определении этих свойств.
Для решения такой проблемы (разные свойства разных сущностей), в РСУБД, мне известно 3 шаблона проектирования (правда не помню как они называются корректно):
1. Все свойства в одной таблице, каждому свойству свой столбец. Если не применимо к данному продукту - NULL.
2. Продукты делятся на "категории с общими свойствами":
2.1 Для каждой категории вводится собственная таблица со всеми свойствами - каждому свойству свой столбец, NULL'ов нет
2.2 Выделяются общие свойства, которые есть у всех продуктов - они лежат в одной таблице, каждой категории заводится отдельная таблица, которая хранит свойства уникальные именно для этой категории.

Четвёртый вариант - это EAV. Пятый - хранить свойства в чём-то типа XML или JSON (этот вариант мне не нравится совершенно).

Я обычно использую 2.2, но у меня можно выделить конечное количество категорий (до 10, обычно).
Если у вас категорий очень много, то возможно EAV и выход, но проблемы с мусором и быстродействием на больших объёмах (когда всё перестанет влезать в память) практически гарантированы (если будет поиск по значениям свойств).

UPD. А, во, нашёл

unfilled, у нас свойства привязаны к иерархии каталога, грубо говоря для каждой конечной папки каталога свой набор характеристик из общего списка характеристик, но при таком подходе будет огромное количество таблиц, я так понимаю когда вы говорите про категории, речь идет о другом, например: Основные свойства, свойства для поиска, прочее и так далее.

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

Максим Зайцев, это я так Class Table Inheritance "адаптировал". Вообще, речь именно про вынос конкретных наборов характеристик в отдельные таблицы.
Вариант со свойствами "для поиска", "прочих" и т.д. всё равно сведётся или к таблице с кучей столбцов, или к EAV, т.к. у разных продуктов будут непересекающиеся наборы характеристик.

unfilled, теперь я понял про что вы говорите, я применял такой подход когда разрабатывал проект для оформления заявок на участие в разных мероприятиях для фестиваля. Там была общая таблица для списка заявок, они были разбиты по типам и для каждого типа была таблица со своим набором полей.

Но в рамках большого интервент магазина не думаю что это применимо, так как разновидностей товаров очень много и под каждый вид плодить таблицы не вариант, что в конечном итоге возвращает нас к началу проблемы. :(