2023.09.22
1. 배달 앱 -> 사용자 , 사업자 구분
// 유저
if (role.equals(UserRoleEnum.USER) && (registNum == null || registNum == 0)) {
User user = new User(username, password, email, role);
user.setPoint(1000000);
userRepository.save(user);
StatusResponseDto res = new StatusResponseDto("회원가입이 완료되었습니다.", 200);
return new ResponseEntity<>(res, HttpStatus.OK);
// 사업자
} else {
User user = new User(username, password, email, role, registNum);
userRepository.save(user);
StatusResponseDto res = new StatusResponseDto("사업자 회원가입이 완료되었습니다.", 200);
return new ResponseEntity<>(res, HttpStatus.OK);
}
- 현재는
UserEntity 의 하나의 필드값을 가지고 사업자, 유저를 구분하고 있다.- 회원가입을 할 때, 유저는 사업자번호를 넣지 않고, 사업자는 입력한다.
- 중복된 값을 방지하기 위해, 컬럼과 유저의 사업자번호는
null로 받기 위해서 @JsonInclude를 활용했다.null은 중복검사 로직에서 제외되기 때문이다.
2. UserRoleEunum 과 필드값을 통한 구분의 차이
📟 확장성의 차이
필드 : 간단한 시스템일 때
이넘 : 추후에 확장성을 고려할 때
registNum -> 필드 값으로 구분
- 갈결성 : 단순히 필드의 값으로 구분하기 때문에 간결 하다.
- 데이터 일관성 : 사업자는 반드시 값이 있기 때문에, 단순히 null여부로 판단 가능하다.
- 가독성 : 코드를 처음 보는 사람의 경우
registNum의 값이 역할을 결정하는지 즉시 이해하기 어렵다. -> 주석, 문서화 필요
UserRoleEnum -> 역할로 구분
- 확장성 : 추후에 다른 유저 역할이 추가되는 경우, 필드만으로는 확장이 어렵다.
- 데이터 성능 : 쿼리를 적게 날릴 수 있다.
📟 확장성의 차이
필드 : 역할별로 다양한 필드를 구성 가능
이넘 : 특정 역할에만 필요한 고유 속성 추가 까다로움
registNum -> 필드 값으로 구분
- 기본 구조: User라는 기본 클래스(또는 인터페이스)가 있으며, 여기에서 필요한 공통 속성들을 정의한다.
그 후, 각각의 사용자 역할을 나타내는 클래스들(예: AdminUser, EditorUser, ViewerUser)이 이 User 클래스를 상속받아 구현 가능하다. -> 필드 또한 확장성 가질 수 있다.- 각 역할별로 고유한 속성이나 메소드를 구체적으로 구현할 수 있습니다. 확장성이 좋다.
- 데이터베이스 설계에서 상속 구조를 표현하는 것이 복잡할 수 있습니다.
(예: 조인 연산을 더 많이 필요로 하게 될 수 있음)
UserRoleEnum -> 역할로 구분
- 기본 구조: 하나의 User 테이블만 있으며, 이 테이블 내에 userRole 필드가 있어 ADMIN, EDITOR, VIEWER 등의 enum 값을 저장한다.
- 단순하고 직관적인 데이터베이스 설계가 가능하다. 쿼리의 복잡성이 줄어든다.
- 모든 사용자 역할이 같은 필드 세트를 공유하므로, 특정 역할에만 필요한 고유한 속성을 추가하는 것이 어려울 수 있다.
3. 성능의 차이가 있나?
필드
- 후반에 갈수록 필드명이 늘어난다면, 그에 따른 테이블의 복잡도와 쿼리 속도가 저하될 수 있다.
- 직접적이고 필드명이 적을 때는 관리하기가 쉽다.
역할
- 확장성이 좋아서 데이터베이스 스키마를 더 깔끔하게 관리할 수 있고, 개별적인 필드 기반 쿼리보다 enum 기반 쿼리가 빠를 수 있다.
- 스키마가 간결해 진다. 시스템이 커진다는 가정하에는 enum 구분이 더 낫다.
👉 예시.
🤷♂️ 1. 왜 필드는 테이블의 쿼리속도와 관계가 있나 ❓
🙆♂️. 여러개의 필드를 가지고 있다면, 테이블의 구조가 복잡해 지고, 이렇게 되면 데이터를 처리할 때
입력,수정,삭제 같은 연산을 할 때 복잡해진다. 또한 다양한 필드를 동시에 조회해야 하는 경우, 성능 저하 발생.
🤷♂️ 2. 왜 enum이 기반으로 한 쿼리가 더 빠를까 ❓
🙆♂️. 이유는 데이터베이스가 enum 필드를 더 효율적으로 인덱싱하고, 스토리지에서 더 효율적으로 관리하기 때문이다. 또한, 하나의 enum 필드만 조회하면 되므로, 여러 개의 boolean 필드를 각각 조회하는 것보다 더 빠를 수 있다.
👉 enum 클래스 또한 여러개의 필드를 가지고 있지 않나? 하나의 필드란 무슨 뜻이지?
👉 👉 👉 UserRoleEnum
👉 👉 👉 User
🤷♂️ 필드의 저장 방식
🙆♂️. 만약에 3개의 역할이 있다면, 테이블에는 세 개의 boolean 필드 (예: isAdmin, isEditor, isViewer)가 생성
사용자가 어떤 역할을 가지고 있는지에 따라 해당 필드의 값은 true 또는 false로 설정됩니다. -> 각 필드에 개수에 맞게 컬럼의 개수가
추가된다. -> (예: isAdmin, isEditor, isViewer) 똑같이 3개 추가
🤷♂️ enum의 저장 방식
🙆♂️.만약에 3개의 역할이 있다면, (예: isAdmin, isEditor, isViewer) -> 테이블에는 enum값 하나만 있고, 그 안에 (예: isAdmin, isEditor, isViewer)의 해당하는 값을 가지게 된다.
알게된 점
- 현재
enum방식으로 구현해야 하는 것을 필드로 구현했다.- 하나의 유저 테이블로 역할을 구분하는 것은
enum인데, 그것을 필드로 구현하고 있었다.- 사업자 번호라는 고유한 값을 입력받기 위해서 필드를 사용했는데, 약간 야매로 섞어서 진행한 듯 하다.
- 시스템이 점점 커진다면 나중에 수정하기 어려워지는 구조다.
- 그러나 지금처럼 미니 프로젝트 느낌의 작은 규모라면 -> 현재 사용하는 방식도 그다지 나쁘진 않아 보인다.
