SQL Server에서의 지연 가능한 제약 조건

SQL Server에서의 지연 가능한 제약 조건

지연 가능한 제약(DC)을 지원하는 SQL Server 버전이 있습니까?

버전 8.0 이후 Oracle에서는 지연 가능한 제약 조건(개별 테이블을 삽입하거나 업데이트할 때가 아니라 스테이트먼트 그룹을 커밋할 때만 평가되는 제약 조건)을 지원했습니다.지연 가능한 제약조건은 제약조건이 여전히 활성화되어 있다는 점에서 단순한 비활성화/활성화와는 다릅니다. 제약조건은 나중에(배치가 커밋될 때) 평가될 뿐입니다.

DC의 장점은 개별적으로 불법인 갱신을 평가하여 결과적으로 유효한 엔드 스테이트가 되는 것입니다.예를 들어, 각 행이 값을 필요로 하는 두 행 사이의 테이블에 순환 참조를 작성하는 것이 있습니다.개별 삽입문은 구속조건을 통과시키지 않지만 그룹은 통과시킬 수 있습니다.

목표를 명확히 하기 위해 C#의 ORM 실장을 SQL Server에 이식하려고 합니다.실장에서는 Oracle DC에 의존하여 행간의 삽입/갱신/삭제 순서를 계산하지 않습니다.

OT: SQL Server가 지원하지 않는 IMHO는 여러 가지가 있지만 기업 환경에서는 의미가 있습니다.

• 여기서 설명한 연기 가능한 제약 조건
• MARS: 완전히 자연스러운 것에 대한 옵션을 설정할 필요가 있는 이유는 무엇입니까?
• 캐스케이드 삭제 제약 조건:SQL Server는 특정 캐스케이드 삭제 제약조건에 대해 단일 캐스케이드 경로만 허용합니다.다시 말씀드리지만 삭제 시 여러 경로를 통해 캐스케이드 처리를 허용해서는 안 되는 이유를 알 수 없습니다.결국 실제로 실행될 때 실제로 사용되는 경로는 항상 1개뿐인데, 이 제한은 왜일까요?
• 단일 ADO에서의 병렬 트랜잭션 방지NET 접속
• 이 트랜잭션 내에서 실행되는 트랜잭션이 있는 연결에서 실행되는 모든 명령어 강제 실행.
• UNIQURE 인덱스를 생성할 때 NULL은 실제 값인 것처럼 처리되며 인덱스에 한 번만 표시될 수 있습니다.그러나 SQL의 NULL 개념을 "알 수 없는 값"으로 지정하면 인덱스를 생성할 때 NULL 값이 완전히 무시됩니다.

이 모든 사소한 것들로 인해 SQL Server에서 풀사이즈 RDBMS에서 기대할 수 있는 참조 무결성 및 트랜잭션 기능의 대부분은 거의 사용되지 않습니다.예를 들어, 지연 가능한 제약조건은 지원되지 않기 때문에, 외부적으로 일관된 작업단위로서의 "거래"의 개념은 부분적으로 부정되며, 일부 더러운 회피책을 제외하고 유일하게 실행 가능한 해결책은 참조 무결성 제약조건을 전혀 정의하지 않는 것이다.트랜잭션의 자연스러운 동작은 원하는 조작의 순서와 방법으로 그 안에서 작업할 수 있는 것입니다.또, 커밋시에 일관성이 확보됩니다.이와 유사한 문제가 발생하는 것은 ON DELETE CASCADE를 사용한 참조 무결성 제약조건은 1개의 제약조건만으로 오브젝트를 캐스케이드 삭제하도록 정의할 수 있다는 점입니다.대부분의 실제 시나리오에는 적합하지 않습니다.

현재 SQL Server에서는 지원되지 않습니다.당신이 풀고 있는 문제는 무엇입니까?

아닌 것 같아요.

약 5개의 다른 블로그 투고를 발견했는데, 모두 SQL Server(다양한 버전)는 Deferrable Constraints를 지원하지 않습니다.

한편, 「지속적인 계산 컬럼」(마지막 엔트리로 스크롤)을 사용하고, 이 기능을 모방하려고 하는 투고도 발견했습니다.

SQL이 Date와 Darwen이 말하는 '복수 할당'을 지원하지 않는 문제가 있는 것 같습니다.이에 대한 표준 SQL의 응답은 SQL Server가 지원하지 않는 '지연 가능한 제약'이었습니다.SQL Server FK 또는 CHECK 제약 조건은 NOCHEK로 플래그를 지정할 수 있지만 완전히 동일하지는 않습니다.자세한 내용은 MSDN: ALTER TABLE(Transact-SQL)을 참조하십시오.

독자적인 ORM 레이어가 있는 경우 ORM 레이어의 논리에 따라 오브젝트업데이트를 참조 업데이트에서 분리하는 것이 문제의 해결책 중 하나입니다.그 후 ORM은 클라이언트 측 변경 설정에 따라 몇 가지 순서로 트랜잭션과 연계됩니다.

1. 변경 세트에 의해 삭제된 것으로 정의된 모든 외부 키 참조를 삭제합니다.즉, 대응하는 외부 키 열을 NULL로 설정합니다.매핑 테이블을 사용하는 관계의 경우 필요에 따라 매핑 테이블에서 항목을 삭제합니다.
2. 변경 집합에서 "삭제"된 개체 모두 삭제
3. 변경 집합에서 모든 새 개체를 생성하지만 아직 외부 키 열을 설정하지 않음
4. 변경 세트의 업데이트된 개체에 대한 모든 "기본" 값 변경을 업데이트합니다. 즉, 외부 키 열을 업데이트하지 않습니다.
5. 변경 세트에 정의된 대로 외부 키 열 값을 설정합니다.
6. 테이블 기반 관계를 매핑하기 위한 매핑 테이블 매핑 추가
7. 저지르다

이렇게 하면 참조되는 모든 객체가 외부 키 값을 설정할 때마다 존재하므로 문제가 해결됩니다.

특정 조건(2017년 1월 현재 SQL Server에서는 지연 제약 조건을 지원하지 않음)에서 누락된 지연 제약 조건 적용을 해결하는 방법이 있습니다.다음 데이터베이스 스키마를 고려합니다.

면책사항:스키마의 품질 또는 사용 사례에 대해서는 여기서 논할 필요가 없습니다. 회피책의 기본적인 예로 제시되어 있습니다.

CREATE TABLE T (Id TYPE NOT NULL PRIMARY KEY, NextId TYPE NOT NULL);

ALTER TABLE T WITH CHECK ADD CONSTRAINT FK_T2T 
FOREIGN KEY (NextId) REFERENCES T (Id);

CREATE UNIQUE NONCLUSTERED INDEX UC_T ON T (NextId);

여기서 TYPE은 대리 키에 적합한 데이터 유형입니다.INSERT 조작 중에 RDBMS에 의해 대리 키의 값이 할당되는 것을 전제로 하고 있습니다(즉, IDITY).

사용 사례는 NextId = NULL인 엔티티 T의 "최소" 버전을 유지하고 단일 링크 목록 T를 유지하여 이전 버전을 저장하는 것입니다.NextId -> T.아이디

새로운 "최신" 버전의 삽입은 이전 "최신" 버전의 업데이트보다 선행되어야 하며, 그 동안 동일한 NextId 값을 가진 레코드가 데이터베이스에 2개 존재하기 때문에 지정된 스키마에는 지연 제약 문제가 발생합니다.

다음 경우:

기본 키의 데이터 유형은 숫자일 필요는 없으며 미리 계산할 수 있습니다(예: UNIQUREIDENTIFIER). 그러면 MERGE 문을 사용하여 다음과 같이 지연 제약 문제를 회피합니다.

DECLARE @MergeTable TABLE (Id UNIQUEIDENTIFIER);

DECLARE @NewLatestVersion UNIQUEIDENTIFIER = NEWID();

INSERT INTO @MergeTable (Id) VALUES (@NewLatestVersion);
INSERT INTO @MergeTable (Id) VALUES (@OldLatestVersion);

MERGE INTO T
USING @MergeTable m ON T.Id = m.Id
WHEN MATCHED THEN UPDATE SET T.NextId = @NewLatestVersion
WHEN NOT MATCHED THEN INSERT (Id) VALUES (@NewLatestVersion);

MERGE 문은 제약 조건을 확인하기 전에 모든 데이터 조작을 완료합니다.

이 방법을 사용할 수 있습니다.

ALTER TABLE your_table NOCHECK CONSTRAINT your_constraint

당신의 행동

ALTER TABLE your_table WITH CHECK CHECK CONSTRAINT ALL

언급URL : https://stackoverflow.com/questions/998095/deferrable-constraints-in-sql-server