fk는 항상 유용한걸까?

[skarltjr]

개요:

jpa를 사용하고 또 연관관계를 사용해오며 한 번도 단점에 대해 생각해본적이없다.
항상 좋고 편리하고 옳은 행위일까? 단점은 없을까?

연관관계에서 마냥 생각없이 fk를 사용하면 문제가 될 수 있다고 생각했는데..

정합성을 강제하는건 좋은것인가?

1. 
   예를들어 학생테이블 / 성적 테이블이 존재한다고 해보자

학생과 성적은 연관관계라고했을때 만약 학생이 졸업한다면? 학생이 사라지면? 성적도사라지는데 졸업하고 성적증명서 뽑아야한다면?

fk의 경우 on delete가 기본이라고한다. on delete 설정은 다음과 같은 종류가 있다

1. CASCADE : 참조되는 테이블에서 데이터를 삭제하거나 수정하면, 참조하는 테이블에서도 삭제와 수정이 같이 이루어집니다.
2. SET NULL : 참조되는 테이블에서 데이터를 삭제하거나 수정하면, 참조하는 테이블의 데이터는 NULL로 변경됩니다.
3. NO ACTION : 참조되는 테이블에서 데이터를 삭제하거나 수정해도, 참조하는 테이블의 데이터는 변경되지 않습니다.
4. SET DEFAULT : 참조되는 테이블에서 데이터를 삭제하거나 수정하면, 참조하는 테이블의 데이터는 필드의 기본값으로 설정됩니다.

예를들어 cascade를 설정한다면 학생을 지웠더니 성적 정보도 같이 사라지게될 수 있다. 만약 fk를 올바르게 인지하지 못하고 사용한다면 위 경우 참사가 발생할것

그러니까.. 주의해야할건 우리가 앞으로 어떤게 필요하고 / 어떤게 필요하지 않을지 쉽게 예상하지 못한다. 결국 "확장 가능 여부"를 고려했을때 무작정 fk 사용은 위험할 수 있다고 생각한다.

2.

다음으로 연관관계가 맺어진 부모 - 자식 테이블이 존재한다고 해보자 부모 테이블 구조를 변경해야하는데 fk가 걸린경우 이게 쉬운가? 부모 테이블 구조 변경으로 인한 영향력을 쉽게 판단할 수 있을까?

분명히 fk의 on delete cascade 처럼 정합성을 위해 연관된 데이터까지 알아서 제거해주는건 정말 효과적이지만 효과적인건 항상 위험이 존재하는것같다.

[skarltjr]

• 

  
  고민해볼 문제
  1. 물리적인 fk를 설정하지 않았을 때라면 연관된 객체를 할당하지 않아도 insert가 된다는거아닌가?

• 애플리케이션단에서 처리 및 검증 로직이 필요할거같다

• joinColumn의 nullable을 통해 검증할 수 있다고 생각

• 그런데 이건 정합성 안맞는경우 서버가 종료되니 위험하다

• 애플리케이션단에서 검증을 통해 예를들어 member객체 생성 전 team id로 team조회 후 존재할때만 member 생성하게하는 검증 로직을 추가한다.

2. 그럼 연관된 객체가 삭제될땐?

• 해당 객체를 삭제할 때 부모에 해당하는. 여기선 team을 삭제할때 연관된 member를 다 불러와서 삭제 후 처리해야한다고 생각

  결국에 fk를 활용해서 편리했던만큼 fk를 사용하지 않을땐 정합성 강제를 피할 수 있는만큼 이에 대응하게 꼼꼼하게 설계가 필요한거같다

[skarltjr]

참고 : https://velog.io/@yrc97/JPA-Foreign-key%EB%A5%BC-%EC%A0%9C%EA%B1%B0%ED%95%98%EA%B8%B0%EB%A1%9C-%ED%96%88%EC%8A%B5%EB%8B%88%EB%8B%A4