DB 테이블 대신 enum으로 정보 관리

[songsunkook]

디스코드 채널에서 나온 질문을 옮긴 discussion입니다.

고민사항

GET /dept, GET /detps API에서 DB 테이블을 조회하여 가져오는 기존 방식 대신 enum으로 관리하는 것이 어떤가에 대한 피드백이 들어왔습니다.

현재 상황

현재 DB에서 위 API에 사용되는 테이블은 deptInfo와 deptNums입니다.

근거

enum으로 관리 시

• 장점: 코딩 단계에서 편리하다, 별도 쿼리를 날리지 않아 속도가 빠르다, 코드가 간결해진다.
• 단점: 수정이 빈번하면 관리하기 힘들 수 있다.

코드 테이블을 enum으로 관리하고자 할 때는 다음 내용이 성립할수록 효과적이라고 합니다.

1. 수정이 거의 없어야 한다. -> O
2. 다른 테이블에서 많이 참조하는 코드여야 한다. (공통 코드여야 한다.)

• join문이 자주 들어올수록 DB 조회가 많아져 리소스가 과하게 소모된다고 이해했는데, 현재 저희 API 상에서는 단 1, 2개의 API만 이 코드를 사용하고 있고 추후에 확장될 가능성이 낮아보입니다. 많이 확장되게 된다면 그 때 가서 enum으로 변경해도 괜찮다고 생각합니다.

참고: https://jojoldu.tistory.com/137, https://tech.socarcorp.kr/dev/2021/08/17/common-code-management.html

DB 테이블로 관리 시

• 장점: 수정이 상대적으로 용이하다, 데이터 정합성을 보장한다. (enum도 가능한지는 잘 모르겠습니당)
• 단점: 쿼리를 날려야 조회할 수 있다, 코드가 복잡할 수 있다.

결론

위와 같이 판단하여 기존처럼 DB에 저장하는 형태를 유지하려고 생각중입니다. 다른 분들의 의견은 어떤지 궁금합니다!

cc. @Choi-JJunho @Invidam @daheeParkk

[Invidam]

데이터 정합성도 결국에는 수정, 삭제, 추가에 따라 어긋나는 일들이 생기는 것 같아요.

23학번부터 (23년도부터) 아예 학번 코드를 000을 사용하니 수정-삭제-추가 작업이 없어질 것 같아 정합성이 크게 중요하진 않을 것 같습니다!

따라서 앞으로 수정되지 않음, 복잡성, 속도를 고려해봤을 때 Enum 사용이 좋을 것 같습니다.

추가로 나왔던 의견들에 대한 생각

• 캐시를 사용하는 방법
  • 속도가 Enum에 비해 느리다. (파일 I/O, TCP 통신 비용이 발생한다.)
  • 정합성을 맞추기 위해 DB와 캐시 모두 수정 작업이 필요하다.
• DB 사용하는 방법
  • 속도가 느리다.
  • 코드가 너무 복잡해져, 나중에 작업할 사람이 이해하기 힘들 것 같다.

[Choi-JJunho]

1년에 1회정도 변경될수도 안될수도 있는 정보라서 Enum으로 관리해도 될 것 같다는 의견입니다~

관련 PR

• feat: GET /dept, GET /depts 구현 #147