나는 stackoverflow에서 개발자 Q & A가 저지른 가장 일반적인 데이터베이스 디자인 실수를 읽고있었습니다 . 처음에는 독점 아크에 대한 문구가있었습니다.
배타적 아크는 둘 이상의 외래 키를 사용하여 테이블을 만들 때 흔히 발생하는 실수입니다. 단 하나의 키만 null이 될 수 없습니다. 큰 실수. 우선 데이터 무결성을 유지하는 것이 훨씬 더 어려워집니다. 결국 참조 무결성이 있어도 둘 이상의 외래 키가 설정되는 것을 막을 수있는 것은 없습니다 (복잡한 검사 제한 조건에도 불구하고).
나는 왜 독점 아크가 악한 지 이해하지 못한다. 아마 나는 그것의 기본을 이해하지 못했습니다. 독점 아크에 대한 좋은 설명이 있습니까?
답변:
오래 전에 이해했던 한 독점적 인 아크 테이블에는 다른 테이블에 대한 외래 키 인 여러 열이 포함되어 있지만 한 번에 하나만 설정할 수 있습니다 (도메인의 논리적 제약으로 인해) 현실에서 따름). 이 규칙을 데이터베이스에서 적용 할 수 없으므로 이러한 외래 키 중 둘 이상에 값이있는 손상된 레코드가 작성 될 수 있습니다.
예를 들어 보겠습니다. 회사가 상품을 배달하는 데 사용하는 트럭을 추적하는 응용 프로그램을 고려하십시오. 트럭은 동시에 세 곳 중 한 곳에만있을 수 있습니다. 직원과 함께있을 수 있고, 주차장에 있거나 정비소에있을 수 있습니다. 이것은 employeeId, parkingGarageId 및 maintenanceShopId와 함께 Truck-table을 가지고 직원, ParkingGarage 및 MaintenanceShop-tables를 참조하여 모델링 할 수 있습니다. 이러한 필드 중 하나만 데이터베이스 수준에서 채워지는 규칙을 적용 할 방법이 없습니다. 잘못된 코드 나 데이터베이스에 직접 액세스 할 수있는 사람은 2 개 또는 3 개의 필드가 채워진 레코드를 삽입 할 수 있으며 이로 인해 데이터베이스의 데이터가 손상 될 수 있습니다.
alter table mytable add constraint myconstraint check ((col1 is not null and col2 is null and col3 is null) or (col1 is null and col2 is not null and col3 is null) or (col1 is null and col2 is null and col3 is not null)). 나는 독점 아크를 좋아하지 않지만 점검 제약 조건으로 시행 할 수 있습니다. 물론 FK 구속 조건도 존재해야합니다.