1. CHAR와 VARCHAR
CHAR와 VARCHAR 모두 문자열을 저장하는 타입이며, 둘의 차이는 문자열 저장 시 오른쪽 패딩을 적용하는가 여부에서 온다. 오른쪽 패딩을 적용한다는 것은 주어진 크기에 맞게 공란을 공백으로 꽉 채운다는 의미인데 CHAR(10)의 경우 10글자 중 5글자만 작성됐을 시 나머지 5글자만큼을 공란으로 채워 10글자로 만들어 저장하고(right-padded with spaces) 이와 다르게 VARCHAR(10)는 저장 가능 공간인 10글자 중 5글자만 채워졌을 때 추가적인 패딩없이 5글자만 채운 상태로 저장한다. 즉, 괄호로 명시하는 값의 의미가 CHAR에서는 글자 수, VARCHAR에서는 최대 글자 수인 것이다.
이를 고려하여 글자 수가 정해지는 필드인 비밀번호 해시값엔 CHAR를, 그 외 가변 길이를 갖는 값들인 제목, 글의 내용, 닉네임 등은 최대 글자 지정의 의미에서 VARCHAR를 사용했다.
2. 이메일 필드는 최대 몇 자까지 허용하는 게 좋을까
지금까지 봐 왔던 이메일 길이를 생각해 지레짐작 20자 정도의 공간이면 이메일 저장에 충분할 거라 생각했다. 하지만 실제로 사용자가 얼마나 긴 이메일을 쓸지는 모르는 일이다.
인터넷 표준을 기록하는 문서인 RFC와 SMTP 프로토콜에 따르면 이메일 길이는 총 254자까지 허용 가능하다고 한다. 이를 참고하여 이메일 필드는 VARCHAR(254)로 설계했다.
참고 링크: RFC 문서
3. 비밀번호 필드의 길이 값은 몇 자로 설계해야 할까
비밀번호는 평문으로 저장하지 않고 암호화해 저장할 것이기에 그 값의 길이는 결정되며 구체적인 값은 사용할 암호화, 해시 알고리즘에 따라 달라진다.
참고 링크:
- What data type to use for hashed password field and what length?(stackoverflow)
- What column type/length should I use for storing a Bcrypt hashed password in a Database?(stackoverflow)
위 두 링크를 통해 각 알고리즘에 따른 암호화 후의 길이 값을 확인할 수 있었고 Bcrypt 해시를 사용할 것이기에 60자로 결정했다.
4. 좋아요 엔터티는 대리키를 필요로 할까? 복합키 사용은 어떤 장단점이 있을까
처음엔 좋아요 엔터티에 대리키는 불필요하다고 생각했다. 좋아요를 id 검색을 통해 접근할 일이 없을 것 같았고 복합키로도 충분히 기능 구현이 가능할 거라 생각했기 때문이다. 하지만 좋아요 알림이 추가되는 등 기능이 확장되고 좋아요가 참조될 일이 생기는 경우엔 복합키로의 참조가 대리키로의 참조보다 훨씬 간편하기에, 대리키가 필요하다는 결론을 내렸고 대리키를 생성했다.