데이터베이스 질문과 답변
안녕하세요, 이번에 데이터베이스 구축 용역을 의뢰한 백엔드 개발자입니다.
용역사에서 준 관계도대로 데이터베이스를 mssql에 밀어 넣으려니 참조 문제로 되지않아 문의를 주었습니다.
그러니까 문제가되는 테이블의 관계를 삭제하고 트리거를 작성하라는 말을 하네요.
트리거를 통해 관련된 테이블의update, insert, delete를 진행하면 된다고 합니다.
구조를 바꾸는게 아니라 트리거를 작성하라는 답변을 받아 굉장히 당황스러운데,
SQL에서 관계 대신에 트리거를 활용하는 방법이 일반적인가요?
데이터베이스 모델링 및 데이터 구축만 맡겨둔 상태라 프로시저, 트리거등의 용역은 힘든 상황입니다.
일단 개인적인 의견입니다.
일단 FK 자체를 운영에서 거의 쓰지 않습니다.
몇일전에 FK 관련 문의가 있었습니다. 참고하세요.
그리고 FK가 있어도 데이블 관계대로 순서에 맞춰서 INSERT / UPDATE / DELETE 하면 문제가 되지않고 그렇게 하는게 맞을겁니다.
저라면 트리거는 안쓰는쪽으로 가겠습니다. 설사 TRIGGER 걸어도 DELETE 시 하위 테이블 부터 삭제해야할겁니다.
아.. DELETE 도 BEFORE 에 넣음 되겠군요.. @@
하나 더 .. 만약 TRIGGER 를 다 걸면..
몇개가 될지 모르지만 TRIGGER 에 대한 관리도 생각하셔야합니다.
FK를 운영에서 쓰지 않는다는것은 관계를 따로 두지 않고 부모 삭제시, 일일이 자식쪽으로 쿼리날려서 처리한다는 말씀이신가요
네 맞습니다.
1. 부모 삭제 시
- 자식이 있으면 부모 삭제를 못하게 하는 경우도 있고
- 자식도 함께 삭제하는 경우도 있고
- 삭제 기능 자체가 없는 경우도 있고(어플리케이션)
2. 해당 제약 조건 구현 시
- FK 로 구현할 수 도 있고
- 트리거로 구현할 수 도 있고
- 어플리케이션에서 구현할 수 도 있고
1. 우선 FK 로의 구현은
- 관계가 있다고 하더라도 FK 설정이 불가능한 경우가 많습니다.(공통코드 등)
- 규모가 큰 시스템의 경우 일부러 안하기도 합니다.(성능저하, 관리비용)
2. 트리거 로의 구현은
- FK 가 불가능한 경우의 대안이 됩니다.
- 다만, 관리 포인트가 많아지는 부담이 있으며
- FK 와 달리 프로그래밍이므로 개발 실수가 있을 수도 있고
- 성능문제 및 예기치 않은 오류 등 여러가지 문제가 있습니다.
3. 어플리케이션에서의 구현은
- 1,2 번이 불가한 경우 대안으로 하는 것이라기 보다는
- 1,2 번과 관계 없이 화면에서 1차로 데이터 정합성 체크하는 것이 일반적인 듯 합니다.
- 1,2번은 3번과 더불어 크로스체크 개념으로 가야 하지 않을까?
- 1,2 번은 (관리비용,성능저하) VS (참조무결성) 을 고려하여 선택과 집중을 해야 합니다.
- 완벽한 정합성이 필요한 중요 테이블의 경우엔 1,2번으로 해야 하겠지만
- 여러가지 비용적 측면을 고려한다면 3번으로 만족해야 할 수 있습니다.
) 버튼을 클릭하여 작성 하시면 됩니다.