MySQL много разных свойств объектов

Определитесь сначала с тем, что это будет за каталог.

Как часто будет появляться новый тип товаров.

Сколько типов товаров сейчас.

Как много товаров.

Как много свойств.

Прочее.

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

Универсальное решение классическое нормальное - таблица товаров, таблица свойств, таблица связей между одним и другим. Но не ждите от этого решения ничего кроме универсальности.

В качестве примера рассмотрим некий аналог например магазина стройматериалов и стройинструментов.

имеем сотни категорий и в каждой категории сотни товаров. (всего 100,000 товаров)

Ну таки да, изредка категории будут добавляться.

Но на самом деле система должна работать одинаково хорошо и для 100 и для 1000 товаров и/или категорий.

• основная таблица с базовыми свойствами товаров;
• таблица рубрик (где указывается id-перечень доп. свойств товаров);
• таблица дополнительных свойств товаров: id-свойства, название свойства;
• таблица доп. свойств к базовой таблице товаров: id-товара, id-свойства, значение;

если сами не понимаете, то можно "подсмотреть" готовые решения, например в Simpla реализован такой каталог с разными свойствами товаров, которые задаются к категориям.

не призываю тупо копировать, но разбираться лучше на примерах))

В общем и целом то, что вам нужно, называется Entity-Attribute-Value EAV - для теоретического ознакомления советую по этому словосочетанию погуглить - как это всё делается и оптимизируется.

Можно просто юзать что-то вроде MongoDB.

Но если подвязаны на что-то вроде MySQL, то да придется повозиться с атрибутами, если по хорошему то еще и с типами этих атрибутов.

Читая всякие форумы, типа stackoverflow, постоянно натыкаюсь на "Don't go with EAV." поэтому и не стал вникать в детали.

Ну а ставить вторую БД типа mongo - выглядит довольно сложным решением по началу.

Попробую посмотреть на "конкурентов"

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

Правильный вариант - держать в двух таблицах, в одной товар, в другой проперти. Будет не устраивать - перейти на тип поля JSON в MySQL. Еще будет не устраивать - перейти на postgresql и HStore . Снова не устраивает , ставим ElasticSearch , загоняем товары в индекс и ищем с абалденной скоростью по любым параметрам.

Проблема быстродействия стоит всегда, т.к. не известно заранее количество объектов.