Здравствуйте. У меня есть продукты с определенными статическими свойствами которые будут постоянно(для примера width и heoght).
Но для некоторых продуктов мне понадобиться добавлять еще какие то свойства- например цвет, вес, мощность. Правильно ли я спроектировал таблицы для добавления дополнительных свойств?

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

_____________
Стимулятор ~yoomoney - 41001303250491

Valick, а можно поподробнее про таблицу связи свойств и продуктов, в которой указываете величину и размерность свойства- это как?

таблица прродукт
p-id - идентификатор строки (примари с автоинкрементом)
p-articul - артикуль
p-name - наименование товара
p-brand - торговая марка (по хорошему в отдельную таблицу, тогда тут b-id)
ну и тд, например количство товара на складе

таблица свойств
s-id - идентификатор строки (примари с автоикрементом)
s-name - наименование свойства

таблица связи продуктов со свойствами
p-id - внешний ключ
s_id - внешний ключ
примари на оба поля p-id, s-id естественно без автоикремента
ps-int - поле для записи цифр (длина, ширина, высота, вес, цвет RGB и тд)
ps-varchar - поле для записи единиц измерения (миллиметров, килограм, красный и тд)

как-то так, хотя херня получается


_____________
Стимулятор ~yoomoney - 41001303250491

AllesKlar, все равно херня
мой вариант даже менее херня чем ваш
тут мало информации по ТЗ, а попытка все сделать универсально приводит к херне

_____________
Стимулятор ~yoomoney - 41001303250491

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

А твой вариант

Так как мне в итоге делать чтобы было правильно?
Как Valick или как AllesKlar?
Может здесь есть настоящие гуру которые уже сталкивались и реализовывали такую задачу?

lodas Знаешь, в проектировании DB нет понятия "правильно", есть понятие "оптимально".

Ты не поленись, выложи десяток товаров и свойств, тогда и сделаем так, как надо, со связями, индексами и прочими тригирами
Да, и что за база? MySql или другое что?


_____________
[продано копирайтерам]

products
product_id INT;
product_name VARCHAR(255);

properties
property_id INT;
property_name VARCHAR(255);
property_type VARCHAR(16);

product_properties
product_id INT;
property_id INT;
property_value BLOB;

property_properties установлен в BLOB потому, что необходимо угодить всем возможным типам в property_type.

_____________
Gear Framework
Gear Framework на Github

linker
Как в админке заполнять будешь свойства для товара?
Ввели товар, выбрали для него свойство, откуда брать значения свойства, прежде чем записать в product_properties?

_____________
[продано копирайтерам]

эта штука которую вы пытаетесь сделать называется Entity-Attribute-Value. У нее единственный плюс - универсальность, зато много минусов с сложностью поддержки, тормознутостью и извращением реляционных отношений. Если у вас не особо много разных атрибутов в планах, к примеру 10-20, да даже 30-50 )), то может лучше не извращаться с EAV а сделать отдельные колонки у товара с энумами, либо с ссылками на отдельные таблички с возможными значениями.

В таблицу properties можно добавить ещё одно поле `property_values` BLOB. Можно ещё добавить поле `property_default_value` BLOB и т.д. пока фантазия не иссякнет.

_____________
Gear Framework
Gear Framework на Github

чтобы не было много лишних NULL-ов, можно сделать так:
например есть табличка товар, у которого есть ширина и высота, делаете табличку
item
width
height

Есть у вас цветная бумага, значит добавляете еще табличку
paper
item_id
color

Есть у вас пылесосы с определенной мощностью, добавляете табличку пылесосов
vacuumer
item_id
power