2014-10-27 5 views
1

Мне нужно хранить похожие продукты с различными атрибутами (например, длиной или цветом), следует ли добавлять эти продукты с разными идентификаторами или как один продукт со многими атрибутами?Хранение подобных продуктов с различными атрибутами

Основная проблема в том, что мне нужна возможность увидеть количество продуктов по атрибуту (4 красных ботинка, 3 синих и т. Д.) И необходимо реализовать селектор атрибутов на странице продукта.

Если вы создаете один идентификатор, как хранить атрибуты в таблице корзины с выбранными атрибутами и как управлять величинами?

Если создать много идентификаторов, легко управлять количеством, но как реализовать выбор атрибутов?

Я думаю о некоторых SKU для связывания идентификатора продукта с атрибутами и значениями атрибутов. Но как соединить все вместе?

ответ

1

Tables хранятся любые данные, которые у вас есть. Если вам нужна какая-либо конкретная информация об этих записях, вы должны использовать разные queries. Например предположим следующую product таблицу:

+----+-------------+-------------+ 
| ID | ProductNAme | ProductType | 
+----+-------------+-------------+ 
| 1 | Product A | Type A  | 
+----+-------------+-------------+ 
| 2 | Product B | Type A  | 
+----+-------------+-------------+ 
| 3 | Product C | Type B  | 
+----+-------------+-------------+ 

Вы можете получить количество Type A продуктов путем написания следующей query (вид This Link для лучшего понимания):

Select count(*) as CountOfProduct from Product where ProductType="Type A"; 

EDIT

Вы упомянули в своем комментарии, что один продукт может иметь разные типы и разные количества. Вы можете сделать это в одной таблице, но это выглядит грязно. Если вы хотите, чтобы это произошло, вам понадобится две сборки: 1-Много **relationship** между двумя таблицами: product и type.

Таблица type может быть что-то вроде этого:

| TYPE_ID | TYPE | 
|---------|--------| 
|  1 | Type A | 
|  2 | Type B | 
|  3 | Type C | 

и ваша product таблица может быть что-то вроде этого:

| PRODUCT_ID | PRODUCTNAME | QUANTITY | TYPE_ID | 
|------------|-------------|----------|---------| 
|   1 | Product A |  3 |  1 | 
|   2 | Product B |  2 |  1 | 
|   3 | Product C |  1 |  2 | 
|   4 | Product C |  5 |  3 | 

** принять к сведению, что type_id является внешним ключом, который строит отношения между этими двумя таблицами. И так как вы можете иметь несколько продуктов с одним и тем же типом (например, продукт C в этом примере), эта таблица будет вашей таблицей many, а таблица типов будет вашей таблицей one. Следовательно, положив foreign key в таблицу many, вы установили связь one to many.

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

select ProductName,quantity,Type from Product p 
inner join type t on t.type_id=p.type_id 

и результат будет то, что вы хотите:

| PRODUCTNAME | QUANTITY | TYPE | 
|-------------|----------|--------| 
| Product A |  3 | Type A | 
| Product B |  2 | Type A | 
| Product C |  1 | Type B | 
| Product C |  5 | Type C | 

Check this link out for the fiddle

+0

Что делать, если у нас есть «Продукт А» с 3-мя различными типами, и нам нужно создать выбор на странице, а продукт может иметь различное количество типов (продукт А имеет тип 1 и 2, типы в моих атрибутах случая), и они имеют собственные ценности? Я не понимаю, как этот пример может решить эту проблему. – Sonique

+0

@Sonique Я отредактировал ответ. Надеюсь, это то, что вы ищете. – Payam

0

Если вы создаете сайт электронной коммерции, это понятие домена, как правило, известен как «вариант»; см. here.

Как правило, у вас есть таблица «продуктов», содержащая основные атрибуты элемента, и таблица «Варианты», связанная с продуктом по идентификатору продукта.

Если вы имеете дело только с подобными продуктами, вы можете иметь таблицу вариантов со столбцами для всех атрибутов (например, размер, цена, цвет); если у вас много разных вариантов (например, одежда, обувь, спортивное снаряжение), вы находитесь на «моделировании наследования с использованием реляционных баз данных»; см. this ответ.

Смежные вопросы