База данных электронной коммерции Справка ERD

Это жарит мой мозг, мне очень нужна помощь! Вот чего я хочу добиться.

У меня есть имя таблицы Product. Продукт может иметь или не иметь до двух необязательных полей. Пример цвета и размера.

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

Я знаю этот звук. Сбивает с толку, извините. Я тоже в замешательстве. ): Но я могу привести несколько примеров ниже.

Итак, вопрос на миллион долларов: какие таблицы и поля я должен создать?

[Товар без необязательного поля]

Цена | Количество

$1.00 | 2

[Продукт с одним необязательным полем]

Цена | Количество | Размер

1,00 долл. США | 2 | Большой

$2.00 | 1 | Маленький

[Продукт с двумя необязательными полями]

Цена | Количество | Размер | Цвет

1,00 долл. США | 2 | Большой | Зеленый

$2.00 | 1 | Маленький | Синий

Мне пришла в голову идея иметь два объекта с именем Product и Optional, чтобы иметь отношение «многие ко многим» с дополнительным объектом для хранения имени поля, например «Размер», а имя соединения-объекта «Product_Optional» будет хранить значение, например «Большой».

Однако я все еще не понимаю, как связать два необязательных поля одного продукта с одинаковой ценой и количеством! ИЗВИНИТЕ, что ввел в заблуждение :(


database database-design erd
person Sydnal    schedule 08.03.2011    source источник
comment
Можете ли вы рассказать нам больше о необязательном поле? Почему он ограничен максимум двумя предметами и есть ли ограничения на количество этих предметов (цвет, вес, размер и т. д.)?   -  person Shane Delmore    schedule 08.03.2011
comment
Ну, два - это предел, который я хочу установить, чтобы было меньше путаницы. И эти необязательные поля могут быть любыми. Примеры, которые я использовал, это размер и цвет, вместо этого это могут быть высота и ширина продукта. Спасибо за ответ!   -  person Sydnal    schedule 08.03.2011
comment
Вы изо всех сил пытаетесь обойти ту функциональность, для которой были созданы реляционные базы данных. У вас есть отношение «один ко многим» (на самом деле их несколько), и вы пытаетесь запихнуть все это в одну таблицу. Это не менее запутанно. Макет таблицы в моем ответе ниже - это подход, который вы должны использовать.   -  person David    schedule 08.03.2011
comment
@Дэйвид. Я полностью не согласен. Построение таблицы EAV также является полным отказом от нормальных форм. Ваша таблица ProductOptions — это анти-шаблон, пример того, чего не следует делать. stackoverflow.com/questions/4066463/should -i-use-eav-model/   -  person Stephanie Page    schedule 09.03.2011
comment
@Stephanie - не стесняйтесь не соглашаться, но не преподносите свое мнение так, как если бы оно было фактом. Даже ссылка, которую вы разместили, была просто артикуляцией плюсов и минусов такого подхода. Он по-прежнему широко используется и действителен во многих случаях. В конце концов, реальный мир — это не университетский курс теории отношений; есть много случаев, когда с вычислительной точки зрения предпочтительнее НЕ нормализовать.   -  person David    schedule 09.03.2011
comment
@ Дэвид, я согласен с тем, что денормализация уместна, я видел слишком много систем, построенных на EAV, которые стали полными кошмарами. Хотя у вас может быть некоторый опыт в проектировании баз данных и вы можете страдать от EAV, большинство людей, которые задают здесь вопросы, являются новичками, и рекомендовать чреватый проектом — медвежья услуга. Если бы вы меня знали, я совсем не нацист из 5NF. Однако запихнуть EAV в РСУБД — это то, с чем я буду бороться всякий раз, когда найду его. Если EAV является лучшей схемой, также рекомендуется переключиться на базу данных, созданную для этого.   -  person Stephanie Page    schedule 09.03.2011
comment
Справедливо. Я соглашусь, что это может стать сложным, если вы заранее не разберетесь со своими требованиями. Мне любопытно узнать, каким будет ваш подход.   -  person David    schedule 09.03.2011

Ответы (2)


arrow_upward
1
arrow_downward

Редактировать:

Поскольку ваши варианты неизвестны, вы можете сделать что-то вроде этого

Продукты

id
product_name
product_description
...

Варианты продукта

id
option (size, color, whatever)
value (large, blue, anything)

ПродуктИнвентарь

id
product_id
product_option_id
quantity
price

Тогда ваши записи в ProductInventory будут выглядеть так:

1 | 1 | 1 | 5 | 2.00
1 | 1 | 2 | 3 | 3.00

и т. д. и т. д.

Более подробный пример с использованием приведенной выше структуры таблицы:

Продукты

1 | Product 1 | Prod 1 Description
2 | Product 2 | Prod 2 Description
3 | Product 3 | Prod 3 Description

Варианты продукта

1 | Size | Small
2 | Size | Medium
3 | Size | Large
4 | Color | Blue
5 | Color | Red
6 | Color | Green
7 | Width | 10 Inches
8 | ... (as many as you want)

ПродуктИнвентарь

1 | 1 | 1 | 5 | 2.00
(says for product 1, size small, there are 5 quantity, and cost is 2.00

2 | 1 | 2 | 17 | 3.00
(says for product 1, size medium, there are 17 quantity, and cost is 3.00

и т.д

person David    schedule 08.03.2011
comment
Спасибо за ответ! Ну, проблема в том, что я не хочу определять необязательное имя поля, то есть ProductSize может быть ProductWidth или чем-то еще. :\ - person Sydnal; 08.03.2011
comment
У вас могут быть поля «Необязательно1» и «Необязательный2» в таблице «Продукты» и вы можете поместить в них все, что хотите, я полагаю. Тогда я не очень понимаю вашу проблему? - person David; 08.03.2011
comment
Да, я тоже об этом. Но для разных значений необязательного1 и необязательного2 может быть разная цена и количество. Например, большой размер синего цвета может стоить 3 доллара, а маленький размер красного цвета может иметь цену 2 доллара. спс за ответ (: - person Sydnal; 08.03.2011
comment
Именно поэтому вам нужно несколько таблиц. Вам нужна одна таблица для продуктов и еще одна таблица для каждого варианта продукта. Таким образом, у вас может быть productID=1, size=small, price=2.00; productID=1, размер=большой, цена=3,00; и Т. Д. - person David; 08.03.2011
comment
Спасибо за ответ! (: Однако мое приложение будет добавлять вариант продукта во время выполнения. Так что я могу получить много таблиц! Размер, ширина, высота, цвет, вес и т. д. Будет ли это хорошим подходом? :\ - person Sydnal; 08.03.2011
comment
Мой отредактированный подход - это путь, поскольку у вас есть неизвестное количество вариантов. Вы можете добавить столько параметров, сколько захотите, во время выполнения, и связь, определенная выше, будет сохраняться. - person David; 08.03.2011

arrow_upward
0
arrow_downward

Я столкнулся с той же проблемой, и я думаю, что вам нужно более одной таблицы. попробуй это:

продукты

id
product_name
product_price
.....

Product_options

id
product_option_name

product_options_values

свяжите свои product_options_values ​​с вашими product_options, используя product_options_id в качестве внешнего ключа. пример: product_option 'size' имеет значения product_option_values ​​'маленький', 'средний', 'большой'*

id
product_options_id (fk)
options_value
options_value_price

product_options_to_products

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

id
product_id
product_options_id
person E.E.33    schedule 09.03.2011