К примеру есть таблица product, в ней есть поля id, name, есть таблица product_price, в ней поля id, product_id, price.
Часто встречаю подобное проектирование и впоследствии, чтобы получить нужные данные продукта приходится по 15 join'ов писать, а это вроде немного влияет на производительность.
В гугле не забанен, но не знаю, как правильно сформулировать вопрос, поэтому если есть что почитать на эту тему - буду рад ссылкам.
есть таблица product, в ней есть поля id, name, есть таблица product_price, в ней поля id, product_id, price.
Мне кажется такое может использоваться если на один продукт есть несколько цен, например одна обычная вторая скидочная которая действует к примеру по выходным...
Джоины давно не проблема в запросах, если есть требуемые индексы
У продукта бывают разные цены - закупка, продажа оптом, продажа в розницу, продажа в кредит, продажа группе зареганых пользователей
Хотя в случае с ценой - логичнее включить все в одну таблицу, если матрица цен не разряжена
Цены имеют свойства меняться.
Как вы сохраните в одной таблице, что продукт с ID=5 сейчас стоит 100 рублей, а в мае он стоил 80 рублей, а в прошлом году 70 рублей? Для отчетности это важно, какая цена была в какой период времени.
А бывают случаи, что цена может меняться в зависимости от количества. Например. 1 шт стоит 100 рублей, но 50 шт. стоит уже 90 рублей.
А еще у одного товара бывают предложения (цвет, размер) у каждого цвета или размера может быть разная цена и оптовоая цена и региональная цена -- в одну таблицу не запихнуть.
Также чтобы у товара указать свойство (например цвет и значение(красный)) нужно всего то прописать в отдлеьной таблице ID товара, ID свойства и значение свойства... и так легко добавлять само свойство ав также его для товара присвоить.
А если красный нужно поменять на бордовый -- или в одном месте или по всей таблице у всех товаров менять
