#title 관계를 끊는 것에 대하여
[[TableOfContents]]

==== 장점 ====
 * 모든 테이블에 대해서 Truncate Table 문을 사용할 수 있다.
 * 다른 테이블에 관계없이 데이터를 갱신, 삭제, 삽입할 수 있다. (개발시 당장은 편할 수 있다.)
 * 갱신, 삭제, 삽입시 참조무결성을 지키지 않아도 되므로 트랜잭션 처리 비용이 관계를 맺고 있는 것보다 더 적게 된다. 

==== 단점 ====
 * DB에서건 어플리케이션에서건 정보시스템의 어디에선가는 이러한 무결성을 지켜야 하기 때문에 데이터티어 이외의 단계가 복잡해 진다. (데이터와 멀어질 수록 복잡해진다. 또한 팀의 긴밀한 협조를 요구한다. 결국 DBA이외의 사람들의 일이 더욱 많아짐을 뜻하기도 한다.)
 * 설계문서가 없다면 후임자등의 사람들이 데이터의 의미파악에 어려움을 격게 된다.
 * 현실에 애써 찾아 놓은 관계를 버리게 되는 것이 되므로 결국 비용이 낭비되게 된다. (물론 찾아 놓은 관계는 데이터티어 이외에서 처리해야 할 것을 미리 데이터티어 이외에서 설계해 두고 관계를 끊었다면 이 항목은 없어져도 될 수도 있다.)
 * 개발시 참조무결성을 지키지 않아 여러가지 오류를 범하고, 성능저하를 유발 할 수 있다.

==== 결론 ====
실제로 많은 DB시스템에서 관계를 끊고 개발하는 것을 볼 수 있다. 개발시 관계를 끊고 개발한다는 것은 매우 위험한 일이라 생각한다. 만약 관계형 DB를 사용한다면 반드시 관계를 끊지 않고 개발해야 한다고 조언하고 싶다. 관계를 끊는 시점은 우리의 정보시스템 어디에선가 참조무결성을 보장한 후에어야 한다. 만약 참조무결성을 위한 부하가 시스템에 부담이 되어 어쩔 수 없는 경우는 어쩔 수 없이 관계를 끊어야 하겠지만...