내가 3 개 테이블SQL 서버 - 행
ParentTableChildTableRecording (열 ParentId 다스 려와 (열 ParentId 다스 려 ParentTable에로)가 자식 테이블 트리거에서 사용할 수없는 부모 테이블 트리거를 통해 추가 소유 테이블로)상위 테이블에 행 int를 추가하는 트리거가 있습니다. o Recording 테이블.
자식 테이블은 다시 Recording 테이블에 행을 추가하는 트리거를 가지고
는 지금은 행이 Recording 테이블
외래 키 같은 테이블에 충돌 INSERT 문에서 찾을 수 없다는 오류가 발생 제약
중복 ParentID가 녹음 테이블에 삽입되도록 트리거 할 수 있습니다. Recording 테이블의 ParentID에 고유 한 키가 정의되어있는 경우에 해당됩니다.
부모 테이블에 삽입 할 때 ParentID가있는 레코드를 녹음에 삽입합니다. 귀하의 삽입 ChildTable 트리거에 대한 중복 ParentID 생각합니다.
아마도 더 많은 컨텍스트를 제공 할 수 있습니다.
또한 가능하면 대부분의 경우 트리거를 피할 수 있습니다. CTE 및 OUTPUT 절을 사용하면 트리거 관련 문제를 피할 수 있습니다.
트리거를 피하기위한 조언에 강력히 동의하지 마십시오. 이것이 데이터 무결성을 보장하는 최선의 방법 일 때가 여러 번 있습니다. – HLGEM
@HLGEM 트리거에는 위치가 있지만 트리거보다 무결성을 강화하는 더 좋은 방법이 있습니다. 중첩 된 트랜잭션과 많은 데이터로 작업 할 때 트리거는 유지 관리 관점에서 볼 때 통증이됩니다. 또한 롤백이 무결성 문제를 일으킬 수있는 많은 시나리오가 있습니다. MS는 방아쇠에서 벗어나고 모범 사례는 모두 동일하게 시작합니다. 잘 코딩 된 CTE를 사용하면 무결성을 강화하는 데 다른 어떤 것도 필요하지 않습니다. – Charl
명확성을 위해 - 나는 트리거를 강력하게 반대하지 않고 단지 피하기 위해 노력하고 있습니다. 시스템이 트리거에 크게 의존하는 경우 트리거를 계속 유지하십시오. 하지만 새로운 것이 있다면 SQL 2008 이상인 경우 항상 트리거보다 더 나은 대답이 있습니다. – Charl
질문에 테이블 및 트리거 정의를 추가하십시오. –