제품 카탈로그 스키마 디자인

Question

제품 카탈로그의 개념 증명 스키마를 구축하여 우리가 사용하는 매우 노후화되고 난잡한 것을 대체 할 수 있습니다.

우리의 사업에서 우리는 물리적 재료와 서비스 (한 번만 반복해서 청구 됨)를 판매합니다.

현재 카탈로그 스키마에는 개별 테이블로 분리 된 각각의 고유 한 범주가 있습니다. 그러나 이것은 잘 정규화되고 잘 수행되지만 확장하기는 상당히 어렵습니다. 특정 제품에 새 속성을 추가하려면 테이블 스키마를 변경하고 이전 데이터를 다시 수집해야합니다.

제가 생각해 보았던 것은 3 번째 정규 형식의 기본 엔티티 테이블 집합을 따라 진행된 것으로, 모든 제품에 공통적 인 사실을 포함하게됩니다.

그런 다음 각 엔티티 유형을 데이터 만 사용하고 스키마를 변경하지 않고 유연하게 확장 할 수있는 Entity-Attribute-Value 스키마를 만들고 싶습니다.

마지막으로이 데이터 모델을 각 개체 유형에 대한 구체화 된보기로 비정규 화합니다. 이러한보기는 응용 프로그램이 액세스 할 것입니다.

비즈니스 규칙 및 호환성 규칙을 포함하는 많은 테이블도 있습니다. 이것들은 뷰 대신 기본 엔티티 테이블에 조인합니다. 여기

내 큰 관심사는 다음과 같습니다

• 실적 - 속성 - 엔티티 값 스키마가 내가 걱정해야 제대로 수행 일반적으로 유연하지만?
• 성능 향상 - 구체화 된 뷰를 사용하여 비정규 화하는 것이 위험을 초래할 수 있습니다.
• 복잡성 -이 스키마는 데이터만으로 유연하고 유지 관리가 가능하지만 설계의 복잡성으로 인해 향후 스키마 변경이 어려워 질 수 있습니다.

대규모 기업용 제품 카탈로그를 설계 한 사람들에게 나는 완전히 잘못된 길을 가고 있습니까? 제품 카탈로그에 사용할 수있는 좋은 모범 사례 스키마 디자인이 있습니까?

Answer 1

하나의 일반 PRODUCTS 테이블을 갖는 것이 좋은 생각이지만 특정 라인에 대해 EAV를 사용할 때 얻을 수있는 이점을 확신하지 못합니다. 솔루션에는 추가적인 유연성이 없습니다. 새 제품을 추가하는 경우 새로운 구체화 된보기가 필요합니다. 기존 제품에 새 속성을 추가하는 경우 구체화 된 뷰를 다시 정의하고 다시 작성해야합니다. 실제로는 데이터를 다시 채우는 것과 다를 바가 없습니다. 단, 오래 걸리는 경우는 예외입니다.

EAV 모델의 성능 및 확장 성 문제가 응용 프로그램이 구체화 된 뷰를 누르기 때문에이 시나리오에서는 적용되지 않는다고 생각합니다 (위에서 언급 한 재구성은 제외). 마 y 가지로, 비정규 화의 성능 저하는 구체화 된보기의 사용에 적용되지 않습니다.

나를 위해 키커는 복잡합니다. EAV와 제대로 정의 된 3NF 테이블을 혼동하는 것은 혼란 스럽습니다. 또한 모든 특정 제품에 대해 데이터베이스에 관계형 무결성 규칙 및 제약 조건을 적용 할 수있는 기능을 잃게됩니다.

제안 된 PRODUCTS 테이블을 유지하고 개별 라인에 대해 하위 유형 테이블을 사용하는 것이 더 나은 해결책이라고 생각합니다.모델링을 마치면 SERVICE_PRODUCTS 및 THING_PRODUCTS와 같은 다양한 유형의 제품에 대한 테이블 계층이 필요하며 비교적 적은 수의 특정 제품에 자체 테이블이 필요하다는 것을 알게 될 것입니다. 일반 뷰를 사용하여 각 제품의 "비정규 화 된"예측을 나타낼 수 있습니다.

Answer 2

필자는 제품 대신 멀티 테넌트 응용 프로그램의 법적 계약을 통해서만 비슷한 문제를 해결했습니다. 일부 속성은 모두에게 공통적이며 일부는 추적을위한 임의의 속성입니다.

나는 EAV가 마약과 같은 많은 경우를 말했습니다. 소량으로 올바른 상황에서 사용하면 효과적 일 수 있습니다. 너무 많이하면 널 죽일거야. 일반적으로 규칙은 "Where Attribute = 'Foo'" 또는 "Where AttributeValue = 'Bar'" 행을 따르는 쿼리를 작성할 수 없도록해야합니다. 보고서 없음, 표시 없음; 아무것도. EAV의 사용은 전적으로 동적이어야하며 특정 속성 행 값의 존재에 의존하지 않아야합니다. 이 점에서 EAV는 데이터 모음 역할을합니다. 그것은 보고서의 목록에서 침을 뱉을 수 있습니다. 사용자가 보고서에 표시 할 속성을 선택할 수 있도록 허용 할 수 있습니다. 할 수없는 일은 특정 EAV 값을 필터링하는 것입니다. 사람들이 같은 문제를 해결하기 위해 XML 데이터가있는 열을 사용한다고 들었습니다. 누군가가 특정 속성을 필터링하려고 할 때, 그 속성을 해당 컬럼의 첫 번째 클래스 속성으로 만드는 트리거입니다.

이 타협안을 어렵게 만드는 이유는 집행입니다. 특정 속성을 필터링하는 쿼리를 작성하는 것이 매우 간단합니다. 보고서 작성자는 경영진의 압력을 받고 나서야 유혹을받을 것입니다. 개발자가 특정 속성에 대해 필터링하지 않는 규율을 강요하기 위해서는 회사의 손이 필요합니다. 그런 종류의 규율을 달성 할 수 없다면 EAV 구조를 선택하는 것을 권장하지 않습니다.