Как моделировать модификаторы цен?

Как моделировать цены на продукты, которые могут иметь или не иметь модификаторы цены. Например, предположим, что у меня есть футболка на продажу разных размеров и разных цветов:

  • Маленький, белый = 10 долларов
  • Маленький, черный = 10 долларов
  • Большой, белый = 15 долларов
  • Большой, черный = 20 долларов

Имейте в виду, что не все модификаторы цены будут "размером" и "цветом". Кроме того, некоторые товары могут вообще не иметь модификаторов цены. Как эта информация должна быть смоделирована в базе данных?

Я чувствую, что должен использовать EAV, но я всегда беспокоюсь, когда начинаю думать о EAV. То, как я бы смоделировал это с помощью EAV,

products
 - id
 - name

prices
- id
- product_id
- attribute
- value

И у меня всегда будет атрибут = «количество» и значение = независимо от цены.

Я обеспокоен тем, что это неправильный способ моделирования таких данных. Предложения/отзывы?


mysql database database-design entity-attribute-value
person StackOverflowNewbie    schedule 18.02.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

это позволяет вам легко иметь и управлять всеми продуктами, атрибутами и атрибутами продукта:

products
 - id
 - name

attributes
 - id
 - attribute_id
 - attribute_name
 - attribute_type

product_attribute_values
 - id
 - product_id
 - attribute_id
 - value

теперь у нас есть проблема с ценообразованием для продуктов с несколькими атрибутами, я думаю, что нужно указать, сколько атрибутов играют роль в ценообразовании (например, два), тогда нам нужно что-то вроде этого:

product_attribute_price
 - id
 - product_attribute_values_id_1
 - product_attribute_values_id_2
 - price

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

person null    schedule 18.02.2015