우리는 tblUsers 테이블이있는 기존 데이터베이스에 추가하려고합니다. 현재 우리는 사용자 이미지를 파일 시스템에 저장하고 있습니다. 이제는 새로운 tblUserImages 테이블에 사용자 이미지를 데이터베이스에 저장하여 그 변화를 보겠습니다.Sql Server는 사용자 당 하나의 활성 이미지 만 허용합니다.
다음은 두 테이블의 모습입니다.
는 난 단지 사용자 당 하나 개의 활성 사진을 수있는 제약 조건을 추가 할 수 있지만이 작업을 수행하는 방법을 모르겠어요. 나는 아무 소용이 그것을 찾고 시도했다. 어떤 도움이라도 대단히 감사합니다! SQL Server에 대해 아직 많이 배워야합니다. 당신은 SQL Server 2008을 사용하는 경우
, 당신은 다음과 같이 필터링 된 고유 인덱스를 만들 수 있습니다
create unique index uniqueUserActiveImages
ON tblUserImage(UserID, Active)
WHERE Active = 1;
이것은 사용자가 여러 비활성 이미지 만 하나의 활성 이미지를 가질 수 있습니다.
나는 트리거의 팬이 아니었지만,이 경우 귀하의 작업을 수행하는 데 도움이 될 수 있다고 생각합니다.
삽입 또는 업데이트시 사용자와 관련된 다른 활성 이미지가 있는지 확인하기위한 트리거를 작성하도록 제안하십시오. 존재하는 경우 사용자 정의 오류를 던지거나 다른 모든 이미지를 비활성으로 설정할 수 있습니다.
트리거 제안은 하나의 이미지에서 n 개의 이미지까지 허용하지만 _active_ 이미지에서만 가능합니다. 고유 색인은 항목을 사용자 당 _active_ 및 _inactive_로 제한해야합니다. –
비활성 이미지에 대해 별도의 항목 (별도의 표)을 마련하는 것이 좋습니다. 이렇게하면 tblUserImages에 "활성"속성이 필요하지 않으므로이 테이블의 모든 이미지가 활성화됩니다. 이미지 기록을 조회하려면 비활성 이미지 표만 참조하십시오. 활성 이미지 테이블은 UserId에 대한 고유 제한 조건을 갖거나 단순히 UserId를 기본 키로 사용할 수 있습니다.
아마도 이것은 밀교적인 해결책처럼 들리지만,이 동일한 데이터 모델링 문제가 다른 시스템에서 나타난 것을 경험 한 경험을 기반으로합니다. 핵심 쟁점은 시스템의 활성 상태가 시스템의 과거 상태와 같지 않다는 것입니다. 활성 상태의 일부를 나타내는 엔티티는 두 엔티티의 정보가 겹쳐도 기록 상태를 기록하는 엔티티와 동일하지 않습니다. 이 아이디어를 사용하여 데이터 모델을 발전 시키면 실제로 역사적인 개체의 특성이 활성 "운영"대상과 다를 수 있음을 알 수 있습니다. 즉, 활성 이미지 테이블의 필드 레이아웃이 과거 이미지 테이블의 이상적인 필드 레이아웃과 정확히 같지 않을 수 있습니다.
이 방법으로 데이터를 구조화 할 때 볼 수있는 유일한 단점은 활성 이미지를 교체 된 지점에서 기록 테이블로 복사해야한다는 것입니다. 몇 가지 중요한 측면에서이 솔루션이 우수합니다. 특히 사용자 ID에 대해 클러스터 된 키를 사용하는 경우 쿼리 속도가 빨라집니다. 가장 중요한 것은 다른 코더가 솔루션을 더 쉽게 이해할 수 있다는 것입니다. 필터 인덱스를 만드는 것은 완벽한 솔루션이며 SQL Server 기능을 잘 사용하지만 향후 유지 관리 프로그래머에게는 분명하지 않을 수 있습니다.
굉장! 매력처럼 작동합니다. 정말 고마워! –
나는 이것이 처음에 제안한 방아쇠보다이 점이 더 마음에 듭니다. –