😮 물리적 FK를 사용하지 않는다?
실제 DB 스키마 구조를 짜다보면, FK가 거의 필수적으로 들어가게 된다. 근데 프로젝트를 진행하다가 "현업에서는 물리적으로 FK를 사용하지 않는다" 라는 이야기를 들었다.
왜지??
일단 물리적FK가 불편했던 경험을 되짚어봤다.
-
성능이슈
물리적 FK를 걸면, 데이터베이스에서는 테이블간의 무결성을 보장하기 위해 제약조건을 설정하게 된다.
따라서, 연관관계가 복잡해질 수 밖에 없는데, 이 관계성이 복잡해지면, 당연히 쿼리에 추가해야할 리소스가 늘어날 수 밖에 없기 때문에, 성능을 하락시킬 수 있다는 단점이 존재했다. -
데이터 삭제(갱신) 문제
물리적 FK를 걸면, 데이터베이스에서 무결성에 의해, 부모 테이블의 레코드를 삭제하면, 자식 테이블의 레코드가 삭제되도록 설계되어있다.
이때, 부모나 자식 테이블에서 오류가 발생하면, 데이터 일관성이 깨지기 되는 경우가 발생하는데 이 때, 부모 엔티티를 삭제하려고 하면 JPA는 컴파일 에러를 내게 된다. -
DB 스키마의 제한적 디자인 (이건 인터넷을 통해 알게된 내용)
FK는 테이블간의 연관관계를 나타내 주기 때문에, 물리적 FK를 걸게 되면, 유연성에 제한이 생겨 자유로운 관계 유형을 제한시킨다.
그치만, 이런 단점에도 불구하고, 데이터의 무결성을 지킬 수 있기 때문에 지금까지의 프로젝트에서 많이 사용했었다.
그럼 왜? 쓰이지 않는 것일까...
첫번째는 귀찮아서다.
현업에서 개발중인 백엔드엔지니어의 말에 의하면, FK를 사용할 경우, 대다수 CASCADE옵션을 사용하는데, 이것을 사용하게 되면, 개발자는 데이터베이스를 생성할 때, 참조되는 릴레이션을 참조하는 릴레이션보다 먼저 만들어야 하는 번거로움이 있다고 한다.
그래서 순서와 늘어나는 데이터양을 모두 신경써야해서 별로 선호하지 않느다고 한다.
두번째는, 실수로 인한 데이터 보존을 위해서다.
CASCADE옵션을 선택한 FK일 경우, 한 릴레이션의 데이터를 실수로 바꿨을 경우, 참조하는 릴레이션의 데이터가 바로 변경되기 때문에 오히려, 데이터가 중요한 시스템에서는 외래 키를 사용하지 않는다고 한다.
세번째는, DBA가 싫어해서이다.
잦은 DB설계 변경시, DBA와 개발자의 소통이 잘 이루어지지 않으면, FK설정으로 인한 로직 강제화 작업이 추가로 생기게 된다.
한마디로, 무결성/정합성을 희생하고, 개발자의 편의와 코드의 안정성/확장성을 위해 사용하지 않는다고 보면 된다.
🥴 그렇다면, 어떻게 DB를 만들까?
인덱스를 활용한다.
DB접근 속도를 높이기 위해, 자주 사용되는 속성에 대해 별도의 테이블을 만들어 해당위치를 찾기위해 인덱스를 사용한다.
(그러나, 인덱스를 만드는 것이 불리할 경우도 있으니, 생각을 잘해보고 만들어야한다.)
외래키에 해당하는 속성에 외래키로 설정하지 않고, 인덱스를 통해 수정을 시켜주게 되는 것이다.
(관련 릴레이션에 대한 데이터를 모두 기억했다가 수정해줘야하니 이것도 귀찮아보인다..)
🐣 나의 생각
나도 실제 개발할 때, FK나 컬럼타입과 같은 부분에서 귀찮음을 상당히 느꼈었는데..
다 똑같았구나.. 싶었다. 그래도 뭔가 암묵적으로 다들 그렇게 쓴다는 게 신기했고, 결국 개발자들끼리 서로 아는 문화면 무조건 룰을 지키는 것보다 오히려 편법이 더 편리하지 않을까 싶었다.
추가로, 이런저런 글을 보다가 컬럼타입도 String(VARCHAR)로 통일해버린 곳도 많다는 글도 봤다ㅋㅋㅋㅋ
사람 사는거 다 똑같군..
