제품 유형별로 별도의 테이블을 만들지 여부

25

데이터베이스를 설계하는 중이며 초기 설계 결정에 대해 다시 생각하고 있습니다 ...

제품 유형은 다음과 같습니다 ... 모델, 부품, 교체 부품 키트 및 옵션.

옵션 A (첫 번째 디자인) : 위의 제품 유형에 대해 별도의 테이블을 계획했습니다. 필드의 약 75 %가 각 테이블에서 동일하다고 말하고 싶습니다.

각 제품 유형을 서로 연관시켜야하기 때문에 각 제품 유형을 별도의 테이블로 작성했습니다. 예를 들어, 모델에는 많은 옵션이 있고 옵션에는 많은 모델이있을 수 있습니다. 옵션에는 많은 부품이있을 수 있으며 부품에는 많은 옵션이있을 수 있습니다.

옵션 B : 별도의 테이블을 사용하는 대신 모델, 부품, 교체 부품 키트 및 옵션을 포함하는 Product라는 테이블을 만들 수 있습니다. 모델, 옵션 등을 구별하기 위해 type이라는 하나의 필드를 가질 수 있습니다. 단점은 특정 제품 유형에 대해 여러 필드가 사용되지 않을 것입니다 (왼쪽 null). 나는 이것이 "모범 사례"가 아닌 곳에서 시작될 것이라고 추측하고있다.

옵션 B는 db 디자인의 복잡성을 크게 줄입니다. 또한 쿼리 데이터를 가져올 때 많은 테이블을 참조하는 것에 대해 걱정할 필요가 없습니다 ...

database-design database-recommendation

— 지불
소스

2

이 위치에서 테이블 레이아웃을 모방하여 데이터로 채우는 스프레드 시트를 만드는 것이 좋습니다. 이것은 존재할 수있는 약점을 노출시킵니다.

— Michael Riley-AKA Gunny

외래 키가 다른 테이블에있는 경우 다른 제품을 어떻게 가리킬 것입니까? 테이블 상속을 읽으십시오.

— Neil McGuigan

8

이것이 나의 디자인 결정 이었다면, 아마도 더 많은 '옵션 C'(수정 된 옵션 a)와 함께 갈 것입니다.

먼저 '옵션 B'가 아닌 이유 :

우선, 각 제품마다 자체 테이블이 제공하는 선명도가 마음에 듭니다. 유형을 결정하는 필드가있는 하나의 큰 테이블이라면 관계가 명확하지 않습니다.

다른 방법으로 인덱싱 전략에서는 항상 해당 유형 필드를 나열해야합니다. 4 가지 유형이므로 인덱스 카디널리티가 매우 낮습니다 ( SELECT * FROM product_table WHERE type='X'기본적으로 전체 테이블 스캔을 수행함)

옵션 C

모든 유형이 공유하는 열만 보유하는 상위 테이블을 작성하십시오.
각 제품 유형을 별도의 열과 함께 개별 열이있는 자체 테이블로 작성하십시오. 상위 테이블에 대한 링크
각 '링크'테이블 (Product_Option, Model_option 등)을 해당 키에 대한 링크로 작성하십시오.
상호 링크 (MODEL_OPTION, OPTION_MODEL)가있는 사용자는 계속해서 해당 테이블을 작성하십시오. 이렇게하면 조인에 명확성을 추가 할 수 있습니다.

단점은 사물이 업데이트 / 삭제 될 때 고아를 피하고 처음에 이러한 테이블을 사용하는 쿼리를 설계하는 복잡성입니다.

— 데릭 다우니
소스

5

현재 4 가지 유형 만 있지만 나중에 더 추가하면 어떻게 되나요? 아마존의 주요 제품 테이블은 원래 "도서"라고 확신하지만 모든 제품 유형에 대해 별도의 테이블이 있다고 생각하십니까? 각 유형마다 고유 한 테이블이 있어야한다고 생각하지 않지만 각 유형에 공통적 인 추가 속성에 EAV 모델을 사용할 수 있습니다.

— Aaron Bertrand

1

@Aaron 제품 유형의 향후 증가에 대한 페어 포인트. 이 시나리오가 10 가지 이상의 제품 유형으로 확장 될 수 있다면 재고 할 것입니다. 그러나 특정 제품 테이블은 소량의 제품 유형에 대한 공정한 디자인 선택이라고 생각합니다.

— 데릭 다우니

1

옵션 C : 연결 테이블이 필요합니까? Product_Option PK가 Product 테이블의 PK와 일치하고 두 테이블을 연결하는 연결을 생성한다고 상상할 수 있습니다.

— 지불

Product_option을 예로 사용하면 스키마는 id, productID, optionID와 같습니다. productID에 대한 FK product.id이고 optionID에 대한 FK option.id입니다. 그것이 링크 테이블의 의미입니다. 예,이 디자인에서는 단일 제품이 여러 옵션에 연결될 수 있어야합니다.

— 데릭 다우니

알았어요 입력 한 내용을 잘못 읽었습니다. 죄송합니다.

— payling

7

옵션 A 인 "올바른"관계형 모델로 시작하는 것이 좋습니다. 해당 모델의 일반적인 사용법으로 인해 일부 영역에서 비정규 화로 이어질 경우 두려워하지 마십시오.

지난 주 동료와 논의하면서 스키마 디자인이 종종 돌로 설정되어 결코 변하지 않는 것으로 간주되는 방법을 논의했습니다. 응용 프로그램의 다른 모든 계층에서 리팩토링이 어떻게 받아 들여 지는지를 고려할 때 데이터베이스 스키마 리팩토링은 여전히 비실용적 인 것으로 간주됩니다.

데이터베이스에 대한 인터페이스가 제대로 설계되어 있으면 시스템 사용 패턴에 대해 자세히 배울 때 스키마를 적용하는 데 방해가되지 않습니다.

— 마크 층-스미스
소스

2

받는 사람과 매우 유사이 소리 재료 / 다중 카디널리티의의 법안 폴 Neilsen가에서 설명하는 heirarcy 장 (17) 의 는 SQL Server 2008의 성경 .

전체 장은 잘 읽었으며 다 대다 문제를 해결하는 특정 섹션은 416-419 페이지에 있습니다.

이것은 분해 부품 유형의 데이터 디자인 에 관해 내가 본 최고의 토론 입니다.

— 마이클 라일리-AKA Gunny
소스

이 솔루션은 옵션 B와 비슷하게 보입니다 (올바르게 이해하면 확실하지 않습니다). 모델, 옵션, 키트 등을 연결하기 위해 마스터 테이블 (제품)과 "링크"테이블 (일명 인접한 테이블 / BillsofMaterials)이 있습니다. 맞습니까?

— 지불

옵션으로 인해 문제가 흐리게 보인다고 생각합니다. 토론에서 약간의 옵션을 취하겠습니다. 부품은 가장 작은 단위입니다. 부품 그룹이 모델을 구성합니다. 키트 형태의 교체 부품 그룹이 모델의 하위 세트를 구성합니다. 여태까지는 그런대로 잘됐다. 이제 부품에는 단순화를 위해 옵션이 있습니다. 여기에는 색상 (검정, 빨강, 크롬)과 재료 (금속, 목재, 플라스틱)의 두 가지 범주가 포함됩니다. 또한 모델에는 옵션이 있다고 언급했습니다. 모델 옵션이 부품 옵션과 분리되어 있습니까? 또는 부품이 모델을 다르게 만들어 모델에 옵션 만있는 것 같습니까?

— 마이클 라일리

내 디자인에는 부품에 "옵션"이 없습니다. 옵션을 확장 된 기능을 제공하는 모델로 사용하는 것으로 정의합니다. 옵션은 부품으로 구성됩니다. 모델에는 다양한 옵션이있을 수 있습니다. 옵션은 다양한 모델에도 적용 할 수 있습니다.

— payling

그것은 당신이 당신의 질문을 표현한 방법이 아닙니다. 인용구 : "예를 들어, 모델에는 많은 옵션이 있고 옵션에는 많은 모델이있을 수 있습니다. 옵션에는 많은 부품이있을 수 있고 부품에는 많은 옵션이있을 수 있습니다 ..." 테이블 레이아웃을 모방 한 스프레드 시트를 만들어 데이터로 채 웁니다. 이것은 존재할 수있는 약점을 노출시킵니다.

— Michael Riley-AKA Gunny

0

네 가지 제품 유형 모두에서 자주 발생하는 쿼리가있을 가능성이 높은 시나리오를 이미징 할 수 있다면 옵션 B가 가장 좋습니다.

제품 테이블에 사용되지 않는 널 입력 가능 필드를 많이 남기지 않고 ModelProduct 테이블, PartProduct 테이블, ReplacementPartKitProduct 테이블을 추가하고 해당 테이블에서 해당 유형에 대해 고유 한 필드 만있는 이유는 무엇입니까? 해당 테이블에서 제품 테이블과 동일한 기본 키를 사용하십시오. 모델에 대해 작업하려는 경우 제품 및 모델 제품 테이블을 결합하십시오. 보유한 제품 레코드가 부품인지 확인해야합니까? Product에서 PartProduct로 왼쪽 조인을 수행하고 PartProduct. [PrimaryKey]가 null이 아닌 경우 Part가 있습니다. 널인 경우 파트가 아닙니다. 또는 ProductType 필드를 Product 테이블에 추가 할 수 있습니다.

— 앨런 맥비
소스

필드의 약 75 %가 모든 테이블에서 사용되므로 널 필드는 최소화됩니다. 제품 유형 간의 관계가 더 걱정되는 것 같습니다. 같은 테이블을 가리키는 세 개의 링크 테이블이 있습니다. Model_has_Option 제품 유형을 나타내는 데 하나의 테이블 만 사용하려는 경우 두 개의 기본 키 (제품 테이블의 제품 ID) 그것이 옳은 일인지 아닌지 더 걱정입니다.

— 지불

"올바른"결정에 영향을 미치는 많은 요소가 있지만 고려해야 할 두 가지 요소가 있습니다. 1 : 전반적인 성능 요구 사항; 2 : 적응성 / 복잡성 / 유지 보수성. 이 두 가지 중 하나가 다른 것보다 조금 더 중요 할 것입니다. 속도가 필요한 경우 옵션 A를 사용하여 비정규 화하십시오. 중복이 발생합니다. 예상됩니다. 정기적으로 스키마를 조정해야하고 속도가 가장 중요한 요소가 아닌 경우 옵션 B. "다른 사람의 모범 사례"를 준수하지 않고 우선 순위를 파악하여 "올바르게"얻을 수 있습니다.

— Alan McBee