к модератору: Я поискал похожий вопрос, но не нашел нужного мне намека или явного ответа. Прошу меня простить, если я не заметил соответствующего вопроса (если найдете, можете перенести, уведомив меня).

к коллегам:
Уважаемые коллеги, я хотел бы посоветоваться (без критики). Я проектирую БД для интернет-магазина. Особенность в том, что заказчик не ориентирован на одну отрасль. Его целевая аудитория - все (!!!). Такое условие мне усложняет проектирование БД, а именно разработку структуры таблицы для хранения данных о товарах. Размышлял даже о глупых методах. Но пока эффективной структуры не определил, может кто даст совет...

-------------
Кратко: Если каждый товар имеет свои атрибуты и они разные у всех, то как тогда проектировать таблицу "Товар"? Свойства одежды отсутствуют в бытовой технике - есть только "размер" и "производитель", но нет таких, как "фасон", "ткань", "воротник".

-------------
Подробно:

Пусть будет таблица "каталог":
IDCatalog - идентификатор записи, первичный ключ
Name - название каталога
ParentID - идентификатор "высшего" каталога, ссылается на эту же таблицу на ключевое поле IDCatalog

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

Таблица "Товар":
IDTovar - идентификатор товара, первичный ключ
Name - название товара
IDCategory - идентификатор каталога
(прочие поля перечислю по русский...)
Ткань (для одежды)
Фирма-производитель (для всех товаров)
Страна, где производился товар (для всех товаров)
размер матрицы (для фотоаппаратов и камер смартфонов)
тип зарядки (для разной техники, например - для смартфонов, цифровых видеокамер, ноутбуков...)
жанр (для книг, музыки, фильма)
объем жесткого диска (для компьютеров)
и так далее

Думаю все уже поняли, с какой трудностью проектирования структуры таблицы "Товар" я столкнулся, но все-таки поясню.
Проблема в том, что товары относятся к разным видам и у каждого вида товара есть свои свойства/атрибуты/технические детали. Например, у телефонах есть камера, сенсорный экран, операционная система, мощность процессора, а у платьев есть длина, фасон, разрез, узор и т.д. Если у одного вида товара есть несколько таких атрибутов, то у другого вида товара может быть десять-двадцать других атрибутов. Что есть у одного, нет у другого ( иногда есть ).
1) Наверное можно в таблице "Товар" перечислить поля типа "Атрибут1", "Атрибут2", "Атрибут3"... Затем в интерфейсе сделать привязку на определенные поля таблицы. В этом случае некоторые "Атрибуты" были бы заполнены, а некоторые нет. Например, для одежды были бы заполнены ткань и фасон, но не было бы объема жесткого диска :) Как-то некрасиво будет выглядеть таблица с точки зрения программиста :)
2) Наверное можно в таблице "Каталог" добавить поле "название таблицы" и значением этого поля указать название определенной таблицы, которая содержит нужные атрибуты конкретного вида товара. Таким образом можно создать таблицы "Юбка", "Брюки", "Смартфон", "Компьютер" и т.д. Возникнет другая проблема - как связать эти таблицы? Или придется в интерфейсе писать sql на выборку из конкретной таблицы?
Есть мысль создать промежуточную таблицу "Тип товара" и тогда можно таблицу "Каталог" связать с "Типом товара", и "Товар" тоже связать с "Типом товара". Приведет ли это к проблемам и каким?

Мне просто нужны идеи. Я и сам спустя время додумаюсь, но может быть кто уже сталкивался с подобными задачами и уже знает эффективное решение? Или может я не учитываю некоторые моменты (подводные камни)...

Благодарю, коллеги, за озвученные идеи. Рассмотрев их все, я нашел для себя вариант, который оптимален на конкретно данный момент - для своевременной сдачи первой фазы проекта вполне годится :)