지연 타이밍은 PostgreSQL의 고유/기본 키 제약 조건 적용에 어떤 영향을 줍니까?

고유/기본 키 제약 조건 연기: 지연 타이밍 조사

PostgreSQL에서 고유 및 기본 키 제약 조건은 연기 가능 여부로 정의될 수 있습니다. 연기 가능. 제약 조건 검사를 연기하면 더 큰 유연성이 제공되므로 제약 조건이 적용되기 전에 데이터 수정이 발생할 수 있습니다.

적용 시기

제약 조건이 연기 가능으로 표시되면 적용 시기는 다음과 같습니다. 초기 설정(IMMEDIATE 또는 DEFERRED) 및 SET CONSTRAINTS를 사용한 모든 후속 변경 사항. 요약은 다음과 같습니다.

• 지연 불가능: 각 행 작업 후 제약 조건 검사.
• IMMEDIATE로 DEFERRABLE: 각 행 작업 후 제약 조건 검사 명령문.
• DEFERRED(또는 INITIALLY DEFERRED)로 DEFERRABLE: 각 트랜잭션 후에 제약 조건을 확인합니다.

예시 분석

주어진 내용을 살펴보겠습니다. 쿼리:

UPDATE tbl SET id = t_old.id FROM tbl t_old WHERE (t.id, t_old.id) IN ((1,2), (2,1));

이 UPDATE는 여러 행에서 작동하므로 고유 기본 키 제약 조건을 위반할 가능성이 있습니다. 그러나 제약 조건이 DEFERABLE INITIALLY IMMEDIATE로 정의되었기 때문에 성공합니다. 위의 규칙에 따라 이는 명령문이 완료된 후 제약 조건 검사가 발생하여 변경 사항이 적용될 수 있음을 의미합니다.

CTE 동작

데이터 수정 CTE, 예제에서 볼 수 있듯이 비슷하게 동작합니다. CTE 내에서 업데이트 순서를 예측할 수 없음에도 불구하고 제약 조건 검사는 전체 CTE가 실행된 후에도 계속 적용됩니다.

여러 UPDATE 문

여러 UPDATE 문이 있는 경우 단일 트랜잭션 내에서 실행되는 제약 조건 검사는 SET CONSTRAINTS 사용 여부에 따라 달라집니다. SET CONSTRAINTS가 없으면 각 문 다음에 검사가 수행되므로 예상대로 고유한 위반이 발생할 수 있습니다.

고유/기본 키 구별

유일하다는 점에 유의하는 것이 중요합니다. 기본 키 제약 조건은 PostgreSQL에서 특별하게 처리됩니다. 연기할 수 없는 고유/기본 키 제약 조건은 각 명령 후에 확인되지만 PostgreSQL에서는 표준 준수 동작을 위해 INITIALLY IMMEDIATE를 사용하여 연기할 수 있도록 정의하도록 권장합니다.

결론

지연된 고유/기본 키 제약 조건의 동작은 특정 시나리오의 예상과 다를 수 있지만 반드시 버그는 아닙니다. 제약 조건 검사를 연기하면 데이터 수정에 유연성이 제공되며 성능을 최적화하고 예상치 못한 오류를 방지하려면 시행 시기를 이해하는 것이 중요합니다.

위 내용은 지연 타이밍은 PostgreSQL의 고유/기본 키 제약 조건 적용에 어떤 영향을 줍니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!