[PA] User 관련 ERD 설계

개요

프로젝트를 진행하며 User에 대해 ERD를 설계했다. 이때 왜 이렇게 설계했는지 판단의 기준 등을 기록해보려 한다.

본문

User(회원)

• id는 Primary key이며 정수이고, NULL이 아닌 항상 값을 할당 받아야 한다. 속성은 1부터 Auto increment를 갖고 있다.
• nickname은 서비스에서 사용할 별명을 저장하며 아직 길이 제한을 갖지 않았다. 제한된 길이를 가질 예정이다.
• email 의 최대 길이는 320이다. RFC 2811에서 찾은 길이 정보는 다음과 같다.

 '${local-part}''@''${domain}'
1) local-part: The maximum total length of a user name or other local-part is 64 characters.
2) @                 : 1 character.
3) domain      : The maximum total length of a domain name or number is 255 characters.

[https://datatracker.ietf.org/doc/html/rfc2821#section-4.5.3.1]

RFC 2821: Simple Mail Transfer Protocol

• picture은 이후에 프로필에서 사용되며 저장될 이미지로 AWS의 S3 주소를 받아 저장할 예정이다.
• available은 계정 활성, 삭제 두 가지 상태를 갖고 있을 예정이다. 아직 영구 삭제에 대한 정책이 결정 되지 않아서 확정하지 않았다. 그러나 사용을 얼마 하지 않을 데이터이기도 하고, 상태가 두 가지이니 boolean이나 정수로 관리 되지 않을까 한다. 확장성을 생각하면 정수나 문자열을 사용하는 것이 올바르게 보인다.
• created_at은 계정 생성 일시를 저장한다. 현재는 사용되지 않지만 유저의 통계 등을 낼 때 유용하게 사용될 것이다. 이후에 삭제 일시나 계정 정보 변동(활성->비활성 등등)의 데이터도 추가될 수 있지 않을까 예상하고 있다.

OAuth(간편 로그인)

• PK는 위에서 이야기한 내용과 동일하다. OAuth table에만 종속적이고 유일한 값이다.
• 하나의 User에 하나의 OAuth 정보가 필요하므로 둘은 1:1 관계를 갖는다. User의 PK를 OAuth가 FK(Foreign Key)로 갖는다. 그러나 OAuth는 PK를 따로 갖고 있으므로 'User - OAuth' 둘은 비식별 관계이다.
• provider는 서비스 제공자로 간편 로그인 기능을 제공하는 서비스 명을 문자열 또는 enum으로 갖고 있을 예정이다.
• provider_id는 서비스 제공자에서 사용하는 유저 식별자로 여러 서비스가 겹치면 이것이 겹칠 가능성이 있기 때문에 이것을 PK로 사용하면 안 된다. 이는 보통 숫자형식이지만 문자열로 반환 되기 때문에 정수로 저장하지 않는다.

결론

User에 대해 간략하게 전체적인 설계를 마무리했다. 해당 서비스는 문제 풀이가 가능한 서비스이다. 때문에 문제 관련 DB도 설계할 예정이다.