복잡한 복잡성 - 까다로운 테이블 조인

나는이 특정 테이블 세트로 얼마 동안 고생했습니다. 3 개의 테이블 (2 개 였지만 3 번째 테이블을 추가해야했습니다)이 있습니다. 표는 Request, PartInfo 및 Status입니다. Request은 테이블에 데이터를 입력하는 양식을 통해 고객이 사용합니다. Status은 Google 서비스 담당자가 고객 요청 진행 상황을 추적 할 수 있도록하기위한 것입니다. PartInfo은 새 테이블로 양 당사자가 액세스하는 공통 데이터를 포함합니다.복잡한 복잡성 - 까다로운 테이블 조인

트릭은 각 요청마다 동일한 테이블에 저장되어있는 해당 요청에 대한 변경 로그가 있으며이 시리즈의 원래 요청에 연결된 자체 결합 키 FirstRequestID을 통해 연결됩니다. '는 약자로 FID). Status 테이블에 대해서도 마찬가지입니다.

Request   PartInfo   Status 
-------   --------   ------ 
ID    ID    ID 
FID    FID    FID 
PartInfoID  PartNum   PartInfoID 
ProductID  Revision   StatusID 
CategoryID  Description  Comments

지금 나는에 대한 정보를 표시 할 말 : (: 더 나은 방법가있는 경우 구조를 변경할 너무 늦게하지 그것의 주) 저는 여기에 현재를 디자인 한 나의 기본 테이블 구조는 ASP.NET GridView 테이블에서 특정 요청 (부품 정보 및 상태 변경 포함). '특정 요청'은 FID으로 식별됩니다.

질문 : 어떻게 내가 요청 내역 또는 상태 역사 중 하나를보고있을 때, 그것은 항상 PartInfo (공유) 테이블에서 적절한 정보를 당기는 것을 보장 할 수 있습니까? 다시 말해, 모든 예외를 설명하기 위해 50 가지 접합 테이블을 갖지 않고 이러한 세 테이블을 적절한 관계로 연결하는 가장 좋은 방법은 무엇입니까?

출처

2012-03-13 Chiramisu

참고로,'Request'와'Status'는 마스터 테이블이고,''다른 사람이 공유하는 세부 테이블입니다. 또한 'CategoryID'는 제품이 아닌 요청의 유형을 나타내지 만,이 세 테이블과 해당 공유 데이터 간의 관계를 정의하는 데 진정한 투쟁이 있기 때문에 이는 중요하지 않습니다.난 그냥 'PartInfo'에서 복사 한 필드를 다른 테이블에 모두 복사 할 수 있다고 가정하지만 적절한 정규화에서 더 나아질 것입니다. – Chiramisu

나는 사과한다. 그러나이 스키마를 처음 사용하는 것은 "이것은 엉망이다." 이 데이터는 정규화되어야합니다. 유감스럽게도 최선의 방법을 결정하는 데 충분한 정보가 없습니다. 귀하의 설명과 부품 이름을 토대로 다음과 같은 아이디어를 제안합니다.

주 엔터티는 요청입니다.
Reqeusts는 의미가 요청 된 제품이 연결된 것을
(이 부품을 포함 카테고리 않는 한)
제품은 부품을 포함 (카테고리는 제품의 속성이 아닌 경우) 제품
요청이 카테고리를 포함 포함 임의의 수의 부품 (해당 제품에 대한 표준화 된 부품 세트와 반대).

상태 (카테고리, 또는 부품 및 제품에 따라 완전히 의존하지 않는)이

REQUESTS 
RequestId 
DateTimeCreated 

PRODUCTS 
ProductId 
-- Add CategoryId, if it’s a Product attribute 

CATEGORIES 
CategoryId 

REQUESTPRODUCTS 
RequestProductId 
RequestId 
ProductId 
DateTimeAdded 
-- Add StatusId if a status entry must be made every time a product is requested 
-- Note extra surrogate key. ReqeustId + ProductId + DateTimeAdded should be the 
-- natural key, unless two identical products can be requested at the same time 
-- (in which case add an “Quantity” column) 


REQUESTCATEGORIES 
RequestId 
CategoryId 
DateTimeAdded 
-- Suorrogate key optional, as it’s not referenced by other tables 
-- Drop, if categories are product attributes 

PARTS 
PartId 

REQUESTPRODUCTPARTS 
RequestProductId 
PartId 
-- Add StatusId if a status entry must be made every time a part is requested 

STATUS 
StatusId 
RequestId 
DateTimeAdded 
Comments

가있어 다음과 같은 테이블을 제안

시간이 지남에 요청의 상태 변화를 추적하는 데 사용됩니다 이것이 갈 수있는 방법의 기록. 결국 "접합점"테이블이 많이 생길 수 있지만 데이터에 참조 무결성이 있으며 정확한 SQL 쿼리가 많이 작성되고 훨씬 간단 해집니다.

출처

2012-03-13 18:15:48

LMBO, oh my ... 나는 실제로 그것이 끔찍한 디자인이라는 것을 알고 있었다. 나는 단지 나의 시간 위기에서 실행 가능하고 빠른 해결책을 내놓으려고 노력하고 있었다. 나는 당신의 의견에 비추어 이것을 다시 생각하기 위해 몇 분 동안 나의 책상에서 벗어날 것이다. 나는'PartID '와'StatusID'로'PartInfo' 테이블의'FID'를 대체하고 다른 테이블들로부터'PartInfoID'를 제거 할 것으로 생각합니다. 이 방법으로'PartInfo' 테이블에 대한 업데이트가'Status'에서 시작된 경우'StatusID' 필드가 업데이트되고 'RequestID'는 변경되지 않습니다. 이게 너가 뭘하고있는거야? 고마워 :) – Chiramisu

아니, 쓰레기. 그것은'RequestID'와'StatusID' 키가 유일하지 않기 때문에 작동하지 않습니다. :(나는 DB 디자인의 초심자이기 때문에 솔루션을 개발하기 위해 배정 된 매우 복잡한 비즈니스 솔루션을 감안할 때 종종 까다로운 문제를 해결해야합니다. 모든 것에 예외가 너무 많습니다. 이 프로세스는 모든 것을 설명하는 것이 매우 어렵습니다.>< – Chiramisu

"시간 위기"가 가장 큰 적입니다. 모델링중인 시스템을 다시 분석하고 가능한 경우 데이터베이스 스키마를 수정해야하는 것처럼 들립니다 (테이블 외.). 더 슬프게도 그렇습니다. 시스템을보다 추상화하거나 자유형으로 만들수록 데이터베이스 아키텍처는 더 복잡해집니다. –

복잡한 복잡성 - 까다로운 테이블 조인

답변

관련 문제