Здраствуйте, вопрос у меня следующий:
Нужно составить базу данных по товарам, причем каждый товар имеет свои свойства, и все их обязательно нужно указывать!

Я сделал следующее:

Код

Если вдруг картинка умерла пишу буквами: Создаю Таблицу Свойств(типа цвет, литраж), и содержания свойств(черный, белый, 2литра ...) и создаю таблицу, с кодом товара, кодом свойства и кодом содержания,....получаеться при 5 свойствах пять записей в последней таблице с одинаковыми кодами товара, но разными кодами свойств и их содержаний. Этот код товара записываю в таблице-каталоге(товаров).

Создавать для каждого товара свою таблицу невозможно, т.к. их очень много!

Мож у кого будут более удачные предложения?
Буду рад любому мнению, заранее благодарен!

Дак пиши все товары в одну таблицу и идентифицуируй каждый из них по его имени. И зачем делать такую глубокую нормализацию? Например, название свойства и содержание свойства связаны как один к одному? Если так, то их можно в одной таблице держать.

Неочень понял, ты предлагаешь держать таблицу свойств такого типа:

1:Цвет:красный
2:Цвет:Желтый
3:Литраж:2л.

Если так, то не слишком ли избыточная будет база?

По имени каждый товар писать немогу, т.к. не у всех есть имена!

Свойства несут описательную или смысловую нагрузку?..

Да, в информации о товаре будет выдаваться список свойств и их описание!
Типа Джинсы: Цвет-Черный, Размер-46, Производитель - Франция!

А выборка по какому-нить свойству производится?.. А то можно было бы их просто все разом в text загнать...

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

К сожалению ты не указал тип базы...
Я думаю, что можно организовать в таблице поле типа text, varchar, varchar2... и туда для каждого товара загонять его свойства... Т.о. для вывода свойств надо будет выбрать только одно поле... Но это решение не подходит, если необходимо будет делать выборку по определенному свойству...

Для поиска по определенному свойству можно конечно написать что-то типа...

SQL

SELECT <Данные> FROM style='color:orange'><Таблица> WHERE <Свойства> LIKE "%цвет - синий%"

Но жрать оно будет на таких выборках... Будь здоров...

Да по свойствам выборку надо будет делать!
А мой вариант нелучше будет? таблицы "свойства" и "описание", я прикреплю JOIN-ом к таблице с товарами, и из этого буду работать, можно также представления создать объединяющие 3 таблицы!
Или это тоже много жрет?

Можно так:

Таблица 1 - товар...
Таблица 2 - название свойства...
Таблица 3 - возможное значение свойства...
Таблица 4 - связь Товар-Свойство-Значение_свойства

Но я бы все-таки рекомендовал сделать по-другому... Товар, какой бы он ни был, может иметь ограничеггое количество свойств... Цвет, размер, цена... Так почему бы не зарегистрировать все эти возможные свойства в таблице товара... Даже если поля таблицы заполняться не будут, то (по крайней мере в Oracle точно) они и места не займут (просто тип им надо дать переменной длины, типа varchar2() )... Тогда и искать можно будет быстро... Вот только одна проблема возникнет - при заполнении/изменении полей много полей придется оставлять пустыми...

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

В своем варианте я создаю таблицу "категории товара" и "соответствия категории и свойств", чтобы пользователь допустим выбрав товар ВОДКА (принадлежащий категории АЛКОГОЛЬ), получил список свойств водки (производитель, литраж, градус)!

Тоже самое касается выборки значения свойств в зависимости от выбраного свойства.

Как решить этот вопрос в вашем варианте базы?

Да точно также... Просто состав полей на вставку свойств будет выбираться из соответсивия категории и свойств товара...

Вообще, хорошо бы разделить общие свойства для всех товаров и качества, уникальные для товара...
Так, например для Водки "Производитель" - общее свойство, "Литраж", "градус" - уникальные...

LIKE много жрать не будет. Проверено на базе 30к записей - примерно 50 миллисекунд.