2015-01-08 1 views
1

"Bill"테이블과 "GeneralArticles"테이블, "CalculatedArticles"및 "AdditionalRecords"테이블간에 m : n 연결이 있습니다.범주에 따른 외부 키 제한

이 표는 간단합니다. 각각은 자체 ID (B_ID, 다른 것들은 GA_ID, CA_ID 및 AR_ID)와 몇 가지 추가 필드를 가지고 있습니다. 질문은 참조 무결성을 보장하는 Bill과이 세 테이블 간의 m : n-connection-table을 설정하는 방법입니다. 그래서 이론적으로 나는 일반 기사 1을 사용할 수있는 등, 당신은 아이디어를 얻을, 나는에 카테고리에 대한 테이블을 설정 한

CREATE TABLE Bill_Articles(
[B_ID] [int] NOT NULL FOREIGN KEY REFERENCES Bill (B_ID) , 
[A_ID] [int] NOT NULL , 
Category [int] NOT NULL 
CONSTRAINT [PK_Bill_Articles] PRIMARY KEY CLUSTERED 
      (
      [B_ID] ASC, 
      [A_ID] ASC, 
      [Category] ASC 
      )) 

:

내 첫번째 생각은 간단하게 만드는 것이 었습니다. 그러나 문제는 카테고리에 따라 다른 테이블을 참조하는 것이 가능하다는 것입니다.

또 다른 해결책은이 범주-ID 및 레코드의 ID가 포함 된보기 생성하는 것입니다 :

Foreign key 'FK__Bill_Ar_A_ID__7526B52E' references object 'Articles' which is not a user table.

다음 Bill_Articles 테이블을 설정할 때이 오류가 불행하게도

Create View Articles 
AS 
Select 1 Category, 
     GA_ID A_ID FROM GeneralArticles 
UNION 
SELECT 2 Category, 
     CA_ID A_ID FROM CalculatedArticles 
UNION 
SELECT 3 Category, 
     AR_ID A_ID 
     FROM AdditionalRecords 

어떻게 든 고유 키를 제공하기 위해 이런 종류의 View를 사용할 수 없습니다.

누구나 이런 종류의 문제에 대한 적절한 해결책을 알고 있습니까? 감사합니다.

+0

기사 테이블의 차이점은 무엇입니까? 귀하의 스키마를 보여 줄 수 있습니까? –

+0

불행하게도 우리는 거대한 테이블을 독일어로 생성하는 시스템을 다루고 있습니다. 그러나 요약하면 : _GeneralArticles_는 선택된 가격과 날짜가있는 Article-Database에서 선택된 기사입니다. _CalculatedArticles_은 실제로 동일하지만 다른 테이블도 참조합니다.이 테이블에는이 기사의 사용에 필요한 특정 수량이 포함되어 있으며 기사 그룹에 대한 정보도 제공됩니다. _AdditionalRecords_는 시스템에 존재하지 않고 관리자가 추가 할 수있는 조항입니다. (일부 기사는 1 년에 1 ~ 2 회만 주문됩니다). – Qohelet

답변

1

일반적으로 이러한 외래 키를 가질 수 없기 때문에 범주별로 열이있는 테이블을 하나 만들지 않습니다.

여러 테이블을 만들어야합니다.

하나의 테이블을 Bills 및 GeneralArticles와 연결할 수 있습니다. Bills와 CalculatedArticles를 연결하는 두 번째 테이블. Bills와 AdditionalRecords를 연결하는 세 번째 테이블. 그것은 다음과 같이 보일 수 있습니다 첫 번째 링크를 들어

은 (내가 구문을 확인하지 않았다) :
CREATE TABLE BillsGeneralArticlesAssosiations(
[B_ID] [int] NOT NULL FOREIGN KEY REFERENCES Bill (B_ID) , 
[GA_ID] [int] NOT NULL FOREIGN KEY REFERENCES GeneralArticles (GA_ID) 
CONSTRAINT [PK_BillsGeneralArticlesAssosiations] PRIMARY KEY CLUSTERED 
(
    [B_ID] ASC, 
    [GA_ID] ASC 
)) 

때때로 나는 기본 키로이 테이블에 IDENTITYID을 추가합니다. 특히이 연결 테이블에 다른 필드가있는 경우

+0

나는 아이디어를 얻었지만 아직 생각하지 못했습니다. 나는 IDENTITY 칼럼을 가진 아이디어를 좋아하지만,이 경우 필자는 이것이 필요하다고 생각하지 않는다. 나는 아마도'ON DELETE CASCADE'를 추가 할 것입니다. – Qohelet

+0

이 테이블을 "적절한 해결책"이라고 부르는 디자인이라고 부릅니다. 또한 개인적으로'ON DELETE CASCADE'를 사용하는 경우는 거의 없습니다. 우리 시스템에서 343 개 중 16 개 테이블에서만 설정됩니다. 필요한 경우 관련 데이터를 명시 적으로 삭제하는 것을 선호합니다. 내가 실수로 잘못된 행을 삭제하려고 할 때 수십 개의 관련 테이블에서 레코드를 지울 위험이 싫어. –