SQL Server의 테이블에 여러 개의 nullable FK를 갖는 것은 나쁜 습관으로 간주됩니까?

13

SQL Server의 데이터베이스 구조에는 주문에 대한 다른 정보가 필요한 3 가지 유형의 제품이 있습니다. 그래서, 하나 개 만든 Customers테이블과 세 가지 주문 테이블 : OrdersForProductAs, OrdersForProductBs, OrdersForProductCs. 모든 주문 테이블은 테이블에 일대 다 관계가 Customers있습니다.

또한 Payments지불 세부 정보가 들어 있는 또 다른 테이블이 있습니다. 그러나 나는 그것을 구성하는 방법에 대해 의문이 있습니다.

여러 제품 유형이 있고 고객이 여러 제품을 동시에 주문할 수 있으므로이 세 가지 주문 테이블을 테이블에 연결해야 Payments합니다.

다른 문제는 고객이 한 가지 유형의 제품에 대해서만 주문할 수 있다는 것입니다. 따라서 Payments테이블 의 FK 열은 이어야 nullable합니다.

내 질문은 그 nullableFK 열이 장기적으로 두통 이 될지 여부입니다 . 일반적으로 테이블에 널 입력 가능 FK 열을 갖는 것은 나쁜 습관으로 간주됩니까?

— 터그 크
소스

2

해당 FK 중 하나 이상 이 null 이 아닌 확인 제한 조건을 포함해야합니다 .

— Damien_The_Unbeliever

3

널 입력 가능 외래 키가 너무 많습니다.

— nvogel

13

나는 왜 당신이 OrdersForProductX테이블 을 가지고 있는지 의문을 제기했다.
당신이 요구 한 FK 문제는 설계 될 수있다.

이러한 테이블의 구조가 동일하면 ProductType일부 OrderProduct테이블에 열이 필요 합니다. 그런 다음 Payment하나의 FK로 연결하십시오.

테이블의 구조가 다른 경우 공통된 특성이 있다고 가정합니다. 따라서 공통 OrderProduct테이블 다음 제품 유형별로 특정 하위 테이블을 가질 수 있습니다 (아래 참조). 다시 Payment한 번 FK가 하나 인 공통 테이블에 연결하십시오.

이것이 "슈퍼 키 / 서브 타입 패턴"입니다

UQ1은 하위 유형 테이블에서 외래 키를 사용하는 "슈퍼 키"입니다.
각 하위 유형 테이블에는 복합 PK 및 FK가 있습니다. (OrderID, ProductType)
각 하위 유형 테이블에는 해당 테이블의 유형을 제한하는 CHECK 제약 조건이 있습니다.

주문 제품

OrderID, PK, UQ1
제품 유형, UQ1
공통 사항 1
...

주문 제품 A

OrderID, PK, FK
ProductType, PK, FK, CHECK ProductType = A
제품 AThing1
...

주문 제품 B

OrderID, PK, FK
ProductType, PK, FK, CHECK ProductType = B
제품 BThing1
...

— gbn
소스

4

@tugberk : NULL이 방법 에는 FK 열 이 없습니다 .

— ypercubeᵀᴹ

"이 테이블이 동일한 구조를 갖는 경우"동일한 구조를 갖지 않습니다.

— tugberk

5

널 입력 가능 "외래 키"를 피하십시오. 그들은 여러 가지 단점이 있습니다.

외래 키에 null이 포함되어 있으면 참조 행의 제약 조건이 항상 적용되는 것은 아닙니다. 그러나 기본 동작은 다른 DBMS간에 일관되지 않습니다. 일부 DBMS는 널 입력 가능 외래 키의 동작을 변경하기위한 구성 옵션을 지원하지만 일부는 그렇지 않습니다. 따라서 SQL 개발자와 사용자는 데이터 무결성 측면에서 Null 허용 외래 키 제약 조건이 실제로 무엇을 의미하는지 명확하지 않을 수 있습니다. 동일한 제품을 사용하여 DBMS 제품간에 또는 심지어 다른 서버간에 데이터베이스를 이식하면 일관성이없는 결과를 얻을 수 있습니다.

데이터베이스 디자인 도구, 통합 도구 및 기타 소프트웨어가 항상 올바르게 지원하지는 않으며 결과가 잘못 될 수 있습니다.

외래 키는 조인 및 기타 쿼리 논리에 자주 사용되므로 제약 조건이 유효하지 않다고 생각하거나 특정 DBMS에 의해 적용되는 논리를 모르는 사용자에게는 문제가 복잡해집니다.

외래 키가 nullable 인 경우 쿼리 다시 쓰기를 허용하는 일부 쿼리 최적화 기능과 다른 최적화를 사용하지 못할 수 있습니다.

논리적으로 볼 때 Nullable "foreign key"제약 조건은 논리적으로 의미가 없습니다. SQL 표준에 따르면 참조되는 테이블이 비어 있어도 이러한 제한 조건을 위반하지 않을 수 있습니다. 이것은 null을 사용하는 가장 일반적인 주장 중 하나와 모순된다- "알 수없는"경우를 나타낸다. 유효한 X 값이 없으면 "알 수없는"X는 확실히 유효한 값이 될 수 없지만 SQL은이를 허용합니다.

널 입력 가능 외래 키는 완전히 필요하지 않습니다. 항상 외래 키를 새 테이블로 분해하거나 수퍼 타입 / 서브 타입 패턴을 사용하여 널이 필요하지 않도록 할 수 있습니다. 단순성과 정확성을 위해 널을 넣는 것보다 널을 남겨 두는 것이 좋습니다.

— 엔 보겔
소스

2

nullable FK 열을 사용하는 것이 나쁜 습관이라고 생각한 적이 없습니다. 다른 테이블을 참조하지만 채워지지 않을 수있는 열에 이상적입니다 (예 : 선택적 데이터).

(왜 문제가 될 것이라고 생각합니까?)

— 스타일스
소스

감사! 글쎄, 나는 확실하지 않지만 몇 년 전 같은 프로젝트를 겪었고 무언가에 두통이 있었음을 기억합니다 . 그래서, 나는 당신이 보는 것처럼 명확하지 않습니다 : s 왜 내가 질문을했는지.