contigent 제약 조건이 적용된 SQL 테이블 디자인

탁월한 솔루션이 필요한 테이블 디자인 문제가 있습니다.contigent 제약 조건이 적용된 SQL 테이블 디자인

의 내가 관계, 두 개의 테이블이 있다고 가정 해 봅시다 :

이제

Contract 1---N Payment

, 이제 나는이 테이블에 갈 필요 레거시 데이터가 있다고 가정 해 보자. 문제는 비록 기존의 지불 항목의 대부분이 대해 여러 개의 계약

에 걸쳐 집계됩니다 있다는 것입니다

그래서 우리는 실제로 볼 수있는 등 :

새로운 기능 :

SomethingAboveContract 1---N Contract 1---N Payment

유산 :

SomethingAboveContract 1---N Payment

이제는 계약과 지불 사이에 MN 관계를 만들어이 문제를 해결할 수 있습니다.

이 기존 데이터에 대한 괜찮

Contract 1---N ContractPayment N---1 Payment

(나에게 모든 집계 지급에 연결되어 계약을 식별하는 것이 가능할 것이다) 그러나 나는 실제로 1-N을 적용하고 싶어 계약과 지불 사이의 관계. 그래서, 설명하기 위해 내 매우 손재주가 낙서를 사용하여, 나는이 일을하고 싶습니다 :

enter image description here

즉, 지불이 집계되는 곳에서는 ContractID가 NULL이되고, 그렇지 않으면 null이되어서는 안됩니다. PaymentID이 ContractPayment에 나타나지 않는 경우 PaymentID가 ContractPayment에

ContractID Null을 허용하지 나타나는 경우

ContractID의 널 (NULL) : 즉, 내가 지불 테이블에 다음과 같은 우발을 적용 할 수있는 방법을 찾을 필요
그래도이 작업을 수행하는 방법을 모르겠습니다.

이것이 가능하다해도,보기 흉한 것처럼 보입니다 (레거시 데이터 변환은 항상 그렇습니다). 그래서 누군가가 위대 할 더 우아한 해결책을 가지고 있다면. 그렇지 않으면 작동하는 모든 것!

감사
칼

출처

2011-05-11 Karl

여러 테이블에 영향을주는 DML 문을 작성할 수 없으므로 닭고기 및 달걀 문제가 발생합니다. 'Payment'에 행이있을 때까지'ContractPayment'에 삽입 할 수 없지만 'ContractID'가 null이고'ContractPayment'에 행이 없으므로 Payment에 원하는 행을 삽입 할 수 없습니다. –

@Damien_The_Unbeliever : "DML"의 정의에서 편리하게'SELECT'를 생략 한 것 같습니다. – onedaywhen

@onedaywhen -'SELECT' ('INTO'가없는)는 * 조작하지 않기 때문에 D * M * L에'SELECT'를 포함하지 않습니다.그리고 비록 우리가 그것을 포함했다 할지라도, 어떤 테이블에 영향을 줄 수있는 SELECT 문을 얻는 방법을 알고 있습니까? (복수의 명령은 말할 것도 없습니다) –

두 개를 사용 (세트) 테이블, 향후 '레거시'에 대한 하나 하나. 널 (null) 열에 대한 필요성없이 비즈니스 규칙을 간단하게 정의 할 수 있어야합니다 (SQL의 세 가지 값 논리는 재앙입니다). 권한이 'legacy'테이블에서 취소되어 앞으로 사용되지 않도록 할 수 있습니다.

출처

2011-05-11 10:36:43 onedaywhen

+1 처음 내 생각을 정확하게. 두 세트의 테이블. 또한 두 테이블을 결합하는 계약에 대한 지불을 받으려면 최소한 하나의보기를 추가하십시오. –

+1 두 세트의 테이블. 가장 일반적인 경우, 새로운 제약 조건에 맞게 기존 데이터를 얻는 것이 불가능할 수 있습니다. 뿐만 아니라 기존 데이터를 최신 데이터와 구분해야 할 때가 있습니다. 별도의 테이블에있을 때 그것은 간단합니다. –

contigent 제약 조건이 적용된 SQL 테이블 디자인

답변

관련 문제