2022-02-19-TIL

2022-02-19-TIL

Today I Learned

실무에서 외래키를 사용하지 않는 이유

외래키 사용 안 하는 이유는 여러가지 있을 수 있는데, 성능면에서도 불리하고 안정성 측면에서도 불리하다.

최신의 애플리케이션에서는 제약조건 관련해서 검증하는 로직을 이미 수행하므로 DB에서 굳이 걸어놓지 않고 애플리케이션에서 코드로 관리한다. 이전에는 DB에서 외래키를 걸어놓고 프로시저로 모두 처리하기도 했는데, 지금은 로직을 모두 애플리케이션에서 수행하므로 필수가 아니게 되었다. DB에 외래키를 걸기 위해서는 릴레이션 설정이 잘 되어있어야 하는데, 실무에서 DBA가 따로 없고 변경이 어려운 상황인데, 제약조건을 이것저것 만들어놓으면 변경이 너무 어렵다. 인덱스의 경우에는 지우더라도 큰 문제가 발생하거나 하지는 안는 반면에, 제약조건은 하나를 지우면 연관되는 테이블에 연쇄적으로 영향이 있으므로 쉽게 지우기도 힘들다. 차라리 부분적으로 에러가 터지더라도 애플리케이션 자체가 돌아가는게 낫기 때문에 애플리케이션에서 외래키를 로직상으로만 관리하는 편이다.

물리적인 외래키를 설정하지 않는 경우 ERD관리

애플리케이션 코드를 통해서 DB ERD를 복원하는게 가능한가? JPA를 통해서는 몰라도 MyBatis로 덕지덕지 발려있는 매퍼들이 있는 레거시 코드의 경우, 코드만 보고 테이블의 개념상의 구조를 복원하는 것은 불가능해 보인다. 그렇다면 실무에서 최선의 선택은 ERD와 완전히 일치하도록 애플리케이션을 개발하고, ERD와 애플리케이션 코드가 일치하도록 지속적인 최신화가 필요하다. 왜냐하면 실제 DB를 보아도 샘플 데이터만 보고 다른 테이블과의 연관성을 파악하는 것은 한계가 있기 때문이다.

• https://www.cockroachlabs.com/blog/common-foreign-key-mistakes/
• https://stackoverflow.com/questions/507179/does-foreign-key-improve-query-performance
• https://dzone.com/articles/the-secrets-of-indexes-amp-foreign-keys
• https://velog.io/@subutai/%EB%A7%A4%EC%9D%BC-2day