복붙노트

[SQL] 다 대다 관계 (제품의 변화)의 조합에 대한 SQL 스키마를 설계

SQL

다 대다 관계 (제품의 변화)의 조합에 대한 SQL 스키마를 설계

나는 제목이 다소 도움이되기를 바랍니다. 나는 내 데이터베이스로 MySQL을 사용하고 있습니다

나는 제품의 데이터베이스를 구축하지 않도록 / SKU 제품의 변화의 저장 가격을 처리하는 방법을 생각하고 있습니다. 제품은 무제한 변화를 가질 수 있고, 각 변형 조합은 자체 가격 / SKU / 등이 있습니다 ..

이것은 내가 내 제품 / 변화 테이블이 순간에 설정 한 방법입니다 :

PRODUCTS
+--------------------------+
| id | name | description  |
+----+------+--------------+
| 1  | rug  | a cool rug   |
| 2  | cup  | a coffee cup |
+----+------+--------------+

PRODUCT_VARIANTS
+----+------------+----------+-----------+
| id | product_id | variant  | value     |
+----+------------+----------+-----------+
| 1  | 1          | color    | red       |
| 2  | 1          | color    | blue      |
| 3  | 1          | color    | green     |
| 4  | 1          | material | wool      |
| 5  | 1          | material | polyester |
| 6  | 2          | size     | small     |
| 7  | 2          | size     | medium    |
| 8  | 2          | size     | large     |
+----+------------+----------+-----------+

(`products.id` is a foreign key of `product_variants.product_id`)

나는이 샘플 데이터로 SQLFiddle을 만들었습니다 http://sqlfiddle.com/#!2/2264d/1

사용자는 어떤 변화 이름 (product_variants.variant)을 입력 할 수 있으며 (product_variants.value)에 값을 할당 할 수 있습니다. 제한을 사용자가 입력 할 수 변형 / 값의 양이이어야한다.

내 문제가 발생하는 곳이다 : 저장 가격 / SKU는 새로운 테이블 / 열을 추가하지 않고 각각의 변화를 때마다 누군가가 이전에 존재하지 않았던 변종에 제품을 추가합니다.

각 변형은 동일한 가격을 가질 수 있지만, SKU 각 제품에 고유합니다. 예 1 제품이 6 개 개의 조합 (3 색 재료 2 *) 및 제품 (2)을 갖는 경우에만 3 가지 조합 (3 개 크기는 1 *)이있다.

나는 텍스트, 즉 같은 조합을 저장에 대해 생각했습니다 :

+------------+-----------------+-------+------+
| product_id | combination     | price | SKU  |
+------------+-----------------+-------+------+
| 1          | red-wool        | 50.00 | A121 |
| 1          | red-polyester   | 50.00 | A122 |
| 1          | blue-wool       | 50.00 | A123 |
| 1          | blue-polyester  | 50.00 | A124 |
| 1          | green-wool      | 50.00 | A125 |
| 1          | green-polyester | 50.00 | A125 |
| 2          | small           | 4.00  | CD12 |
| 2          | medium          | 4.00  | CD13 |
| 2          | large           | 3.50  | CD14 |
+------------+-----------------+-------+------+

그러나이 데이터를 표현하는 더 나은, 정규화, 방법이 있어야합니다. 가설 상황 : 나는 $ 10 미만이다 파란색 제품을 검색 할 수 있어야합니다. 위의 데이터베이스 구조와 텍스트를 구문 분석없이 할 수 없습니다 그것은 내가 피하고 싶은 무언가이다.

어떤 도움 / 제안 감사합니다 =)

해결법

  1. ==============================

    1.문제에 정상화를 적용 솔루션은 다음과 같이 주어진다. 실행하고 바이올린에 볼

    문제에 정상화를 적용 솔루션은 다음과 같이 주어진다. 실행하고 바이올린에 볼

    깡깡이

    CREATE TABLE products 
        (
         product_id int auto_increment primary key, 
         name varchar(20), 
         description varchar(30)
    
        );
    
    INSERT INTO products
    (name, description)
    VALUES
    ('Rug', 'A cool rug'  ),
    ('Cup', 'A coffee cup');
    
    create table variants (variant_id int auto_increment primary key,
                           variant varchar(50)
                           );
    insert into variants (variant)
    values ('color'),('material'),('size') ;   
    create table variant_value(value_id int auto_increment primary key, 
                               variant_id int ,
                               value varchar(50)
                               );
    
    insert into variant_value (variant_id,value)
    values (1 ,'red'),(1 ,'blue'),(1 ,'green'),
            (2 ,'wool'),(2 ,'polyester'),
            (3 ,'small'),(3 ,'medium'),(3 ,'large');
    
    
    
    create table product_Variants( product_Variants_id int  auto_increment primary key,
                                product_id int,
                                productVariantName varchar(50),
                                sku varchar(50),
                                price float
                                );
    
    
    
    
    create table product_details(product_detail_id int auto_increment primary key,
                                 product_Variants_id int,
    
                                 value_id int
                                 );
    
    insert into product_Variants(product_id,productVariantName,sku,price)
    values (1,'red-wool' ,'a121',50);
    
    insert into product_details(product_Variants_id , value_id)
    values( 1,1),(1,4);
    
    insert into product_Variants(product_id,productVariantName,sku,price)
    values (1,'red-polyester' ,'a122',50);
    
    insert into product_details(product_Variants_id , value_id)
    values( 2,1),(2,5);
    
  2. ==============================

    2.당신의 문제의 일부는 제품 SKU 사이의 혼란에서 줄기.

    당신의 문제의 일부는 제품 SKU 사이의 혼란에서 줄기.

    당신이 판매하는 경우, "XYZ의 풀오버, 사이즈 M, 블루 모델", SKU에 후자에 해당합니다. 그것은 특성 (크기 및 색상)의 집합이있는 XYZ 풀오버 (제품), 잠재적 인 가치의 자신의 세트와 함께 각으로 판매된다. 그리고 후자의 모든 가능한 조합은 유효 결과물을 얻을 수 있습니다 당신이 터무니없이 가늘고 긴 청바지를 찾을 수 없습니다. SKU를, 상품, 속성, 속성 값.

    사용자가 $ 10 파란색 스웨터를 원할 때, 그는 실제로 제품 카테고리 내에서 SKU을 찾고.

    나는 위의 투명 도료 당신의 혼란까지 어디에 문제 및 질문에서 줄기 바랍니다.

    스키마의 측면에서, 당신은 이런 식으로 뭔가를 원하는 :

    선택적으로, 또한 추가 :

    이것은 마케팅 관련 테이블입니다. 다른 건 없습니다. 마케팅 아무것도 외부 응용 프로그램에서 제품을 사용하는 경우, 도로의 아래 고통의 세계에 끝날 것입니다.

    가격은, 존재하는 경우 필드를 채우는 데 사용되는 마스터 가격 일 때의 SKU에 그것의 널 (null). 이 가격 항목을 더 사용자 친화적한다.

    IN_STOCK 이상적 트리거에 의해 유지되는 희망 자체 explanationary 플래그입니다. 해당 제품에 관련된 모든 SKU의 재고가 있다면 그것은 진정한해야합니다.

    이것은 단지 파란색, 빨간색, S, M, L. 같은 자신의 값과 함께 등 색상, 크기, 같은 것들을 보유

    PRODUCT_ID 필드를 참고 : 제품 별 속성과 값의 새로운 세트를 만들 수 있습니다. 크기는 제품에 따라 달라집니다. 때로는 S, M, L 등이다; 다른 시간, 그것은 38, 40, 42, 그리고 무엇을하지 수 있습니다. 때때로, 크기는 충분하다; 다른 시간, 당신은 폭과 길이가 필요합니다. 블루는이 제품에 대한 올바른 색상 수 있습니다; 또 다른 해군, 로얄 블루, 청록 무엇을하지를 제공 할 수 있습니다. 하나 개의 제품의 속성과 다른들 사이에 어떤 관계가 있다고 가정하지 마십시오 그들이 존재하는 경우의 유사성은 전체 화장품 및 우연의 일치입니다.

    선택적으로, 추가 :

    제공받을 결과물이 해당한다.

    실제로 가장 중요한 테이블 아래에 있습니다. 오히려 PRODUCT_ID보다이, 고객의 주문에 언급 취득해야하는지 거의 확실하다. 그것은 재고 유지를위한 등등를 기준으로 취득해야하는지이기도합니다. (당신이 정말로 일반적인 뭔가를 판매 할 때 내가 후자의 두 지점에 본 적이 유일한 예외이다. 그러나 그렇다하더라도, 내 경험이 처리 할 수있는 더 좋은 방법은 교환 SKU를 사이에 n-m 관계에 던져하는 것입니다.)

    이름 필드는, 당신이 그것을 추가하는 경우, 주로 편의를 위해입니다. 왼쪽 null의 경우, 사용하는 응용 프로그램 측 코드는 관련 속성 이름과 값이 필요한 경우 확장 된 일반 제품의 이름에 해당합니다 확인합니다. 이 후자의 일반적인 이름을 바꿔 할 수 있도록 작성 ( "리바이스 ': L, 32 : W, 501 32, 색상 : 다크 블루") 자연 뭔가 ('리바이스 '501, 32 × 32, 다크 블루 ").

    이 중요한 경우, 주식은 더 나은 백그라운드에서 복식 부기 스키마, 장기적으로 트리거를 사용하여 유지됩니다. 이것은 재고 대 (당신이 실제로 여기에 원하는 그림 인)하지만 이미 접하게하는 실제 시나리오의 무리들, 판매 오늘 재고 및 선적 사용할 수를 구별 할 수 있습니다. 혹시 킬로그램 또는 리터로 측정 판매 아무것도 필요하면 아, 그리고 ... 그것은 오히려 정수보다, 가끔 숫자입니다. 그렇다면, 0.1 노트북 당신에게 주문을 보내는 고객을 피하기 위해 별도의 is_int 플래그를 추가해야합니다.

    이 기본 이름을 생성하기 위해서, 해당 속성과 값으로 결과물의 ID를 연결합니다.

    기본 키 (sku_id,은 attribute_id)에 있습니다.

    당신은 PRODUCT_ID 필드에게 aberrance를 찾을 수 있습니다. 당신이 참조하는 외래 키를 추가하지 않는 한 그것은이다 :

    (당신이 외래 키를 추가하려는 경우 음주 해당 튜플에있는 여분의 고유 인덱스를 잊지.)

    결론적으로 세 개의 추가 발언.

    첫째, 나는 흐름의 관점에서가 아니라 속성과 값의 모든 조합이 유효한 결과물을 얻을 수 있음을 다시 한 번 강조하고 싶습니다. 폭은 28-42 될 수 있으며 길이는 28-42 수 있습니다,하지만 당신은 아마 심각하게 마른 28x42 청바지를 볼 수 없습니다. 자동 기본적으로 모든 제품의 가능한 모든 변화를 채우는 최고의 해제하지 않은 : 이름, 바코드 및 가격 필드와 함께, 필요에 따라 사용 안 함 / UI가 가능하도록 추가는 기본적으로 선택합니다. (이름과 가격은 보통 공백으로 남아있을 것입니다,하지만 당신은 다른 옵션을 계속 판매 할 어느 날, 당신은 색상이 중단됩니다 만, 근거에 파란색 스웨터에 판매를 구성해야합니다.)

    혹시 추가로 제품 옵션을 관리해야하는 경우 둘째, 많은 사람들이 실제로 제품이 재고 유지에 올 때 또한 고려되어야 새로운 SKU는 산출되지 않은 사람들을 변장 속성, 그 것을, 명심하십시오. 노트북에 대한 더 큰 HD 옵션은, 예를 들어, 인해 (매우 유효) UI 고려 사항에 정말 옵션으로 가장 한 동일한 제품 (일반 대형 HD 크기 대)의 변형이다. 반면에, 크리스마스 선물로 노트북을 포장하는 회계 용어 참조 완전히 별도의 SKU가 정품 옵션 (예 : .8m 선물 포장의) - 당신은 지금까지 평균 한계 비용을 마련 할 필요가 있어야하고, 분수 직원 시간.

    마지막으로, 당신은 당신의 속성, 속성 값 및 이후의 변종에 대한 주문 방법을 마련해야합니다. 이를 위해 가장 쉬운 방법은 속성과 값 테이블에 추가 위치 필드에 던져하는 것입니다.

  3. ==============================

    3.나는 4 개 테이블을 사용합니다 :

    나는 4 개 테이블을 사용합니다 :

    generic_product: product_id, name, description 
    

    EG 1 aruga, RBA tsoffee 루가 / 2 amuga, RBA의 tsoffee의 무가 (MUGA) 검사

    generic_product_property: product_id, property_id, property_name 
    

    예를 들면 1, 10, '색상'/ 1, 11, "재료"

    sellable_product: sku, product_id, price 
    

    EG A121, 1 50.00 / A122, 1, 45.00

    sellable_product_property: sku, property_id, property_value 
    

    예를 들면 'A121', 10 '적색'/ 'A121', 11 ', 양모'/ 'A122', 10 '그린'/ 'A122', 11 ', 양모'

    이것은 사용자가 자신이 원하는 당신의 판매 가능한 제품에 대한 모든 속성을 정의 할 수 있습니다.

    응용 프로그램이 sellable_products이 (모든 적용 가능한 범용 제품 속성에 대한 판매 가능한 제품 속성이 정의되어 있는지 확인) 완전히 설명되어 비즈니스 로직과 보장해야합니다.

  4. ==============================

    4.이것은 내가 SO에 잠시 뒤로 그녀를보고 또 다른 질문과 유사하다

    이것은 내가 SO에 잠시 뒤로 그녀를보고 또 다른 질문과 유사하다

    더 나은 방법은 다음과 같습니다 데이터베이스를 설계?

    당신이 살펴 경우가 당신은 기본적으로 대 폭 넓은 테이블 질문 같은 좁은 (기반 속성)을 요구하는 것을 볼 수 있습니다. 나는 두 시나리오에 따라 사용했습니다,하지만 난 당신이 지금 당장 구현이 정말 조심 방법이있을 것입니다. 그리고 정말 일치하는 좋은 방법이 아니라는 사실은 테이블을 변경하도록 강요 할 수있다 (적어도하지 내가 생각할 수 있음)을 SKU를에 변형.

    당신이 이렇게 많은 다른 변형이있는 경우 당신은 또한 키 - 값 데이터베이스, 또는 다른 NoSQL에 솔루션을 조사 할 수 있습니다.

  5. ==============================

    5.일반적인 관점에서, 당신은 그룹화 또는 정크 차원이라고 무엇을 찾고 있습니다. 기본적으로 모든 조합에 대해 단지 행입니다. @ sahalMoidu의 스키마 외모는 당신이 요구하는 무엇을 제공해야처럼.

    일반적인 관점에서, 당신은 그룹화 또는 정크 차원이라고 무엇을 찾고 있습니다. 기본적으로 모든 조합에 대해 단지 행입니다. @ sahalMoidu의 스키마 외모는 당신이 요구하는 무엇을 제공해야처럼.

    그러나 정상화에 끊었도하기 전에, 당신은 DB가 (트랜잭션 등) 데이터를 저장하거나 (차원,보고 등) 데이터를 얻기 위해가있는 경우 알 필요가있다. 이 트랜잭션 데이터베이스입니다하더라도, 당신은 당신이 정상화 달성 하려는지 스스로에게 물어해야합니다.

  6. ==============================

    6.SKU는 기본 키입니다. 당신은이 SKU를 가진 테이블을 변형에 설치 외래 키 관계를 할 수 있습니다. 제품 ID에 대해 완전히 잊어 버려.

    SKU는 기본 키입니다. 당신은이 SKU를 가진 테이블을 변형에 설치 외래 키 관계를 할 수 있습니다. 제품 ID에 대해 완전히 잊어 버려.

    테이블 X 만들기 (SKU, 가격, 설명) 기본 키 SKU

  7. from https://stackoverflow.com/questions/19144200/designing-a-sql-schema-for-a-combination-of-many-to-many-relationship-variation by cc-by-sa and MIT license