💬 들어가기 전 사담
팀원들이 보고서 작성으로 바빴던 어느 날...나는 보고서에 쓸 와이어프레임과 디자인을 작성하고 있었다. 이전에 백엔드들을 관찰한(?) 결과로는 대강적인 와이어프레임이 나와야 DB와 API 명세를 짤 수 있었다.
디자인 하는 손은 좀 빠른지라 진작 끝내고 할 거 없나 기웃거리고 있는데, 같은 백엔드 팀원이 숙제를 줬다.
🦝 : ERD 한번 짜봐!
🐰 : 례? 갑자기?
📝 DB에는 어떤 값이 들어가야 할까?
까짓것 한 번 해보죠. 각설하고 만들어진 시안을 보며 각 페이지마다 어떤 정보가 필요한지 먼저 적어 보았다.
페이지마다 어떤 값이 필요한지 파악하고 그 후에 테이블을 구성해보았다
원래 쓰던 언어가 JavaScript와 TypeScript이다보니 자료형 지정도 비슷하게 흘러갔다. 예를 들면 int를 number로 적는다던가...
테이블을 구성하고 팀원에게 설명했다. 자료형은 TypeScript 영향을 받아서 이런데, number는 int로, 배열은 이런 식으로 해놨다는 추가 설명과 함께 어떤 부분이 관계형으로 들어가면 될 지 얘기했다.
📝 피드백 결과
그리고 검사 받았다.
검사받은 결과
정리된 내용은 다음과 같다
-
DB에서 배열은 들어가지 않는다
이번 프로젝트에서는 MariaDB를 사용한다. 다른 DB와 다르게 MariaDB에서는 배열을 지원하지 않기 때문에, 이 부분을 정정해주면서 테이블 간 관계를 더 활용하면 된다는 피드백을 들었다. -
이미지를 넣을 때는 BLOB보다 경로를 이용하자
둘 다 이미지를 저장한다는 점은 같지만, BLOB의 경우 이미지 정보 자체를 들고있다 보니 상대적으로 무겁기 때문에 이미지로 연결되는 경로를 String으로 저장하는 것이 훨씬 효율적이라고 한다. 뿐만 아니라 이미지를 수정하거나 변경할 때도 경로를 사용하는 것이 더 용이해서 선호한다고 한다. -
created_at과 updated_at
컬럼의 생성과 수정 시간을 기록함으로써 데이터를 효과적으로 추적/ 관리할 수 있다고 한다. 데이터의 무결성을 보장할 수 있고, 불법적으로 데이터를 수정하거나 삭제하는 시도를 파악해서 보안성을 높이는 데도 유용하다고 한다. 그래서 모든 컬럼에는 생성일자인created_at와 수정일자인updated_at가 필요하다고 한다.
이때 모든 컬럼에 공통적으로 들어가는 요소는BaseEntity로 뺀 후 그것을 상속 받는다고 한다. -
Base64
🐰 : 비밀번호가
string...varchar...이쪽 계열인 건 알겠는데, 길이 설정을 얼만큼 잡아야 해?
🦝 : 우리는 Base64 쓸 거라, 그거 맞춰서 하면 돼.
🐰 : 그게 먼디?!난생 처음 들은 Base64...간단하게 말하면 암호화하는 거란다. 그래서 좀 더 찾아보았다.
Base64는 8비트 이진 데이터를 ASCII 영역의 문자로만 이루어진 일련의 문자열로 바꾸는 인코딩 방식이다. 64진법을 사용하는 이유는 64가 2의 제곱수이며, ASCII 문자를 써서 표현할 수 있는 가장 큰 진법이라서라고 한다. 이걸 바탕으로 인코딩해서 암호화된 문자를 만든다고 한다. 이렇게 하면 신뢰할 수 없는 통신에서도 이진 데이터가 안전하게 전송되기 위해 사용된다고 한다. 받은 이진 데이터를 디코딩하면 저장된 내용을 사용할 수도 있고 말이다!
위의 방법을 이용하여 변환하면 크기가 대충 50 정도 되는데, 우리 팀은 좀 더 넉넉잡아 크기를 70으로 잡을 예정이라고 한다.
-
varchar과 String
가만 듣다보니 다시 의문점이 들었다. 내가 알고 있는 게 맞는지, 다시 질문해보았다.🐰 : 그럼
varchar이면 Java에선 String인거지?
🦝 : 그치. DB에서 사용하는 자료형이varchar인 거.char도 있긴 한데 차이가 좀 있음.둘 다 문자열이긴 하다. 하지만 다음과 같이 나뉜다고 한다.
char은 고정형으로, 255자까지 대응
-> 고정형이기 때문에 추가 연산이 필요 없어 다른 타입보다 속도가 더 빠르다고 한다.varchar은 가변형인데, 범위가 넓기도 하고 문자 수의 상한은 이용하는 문자 코드에 따라 다름.
-> 그래서 데이터의 길이에 따라 가변적으로 길이가 정해지는 특성이 있다.
여느 코드가 그렇듯, 상황에 따라 적절히 사용하는 게 중요하다고 한다.
📝 ERD를 짜보자!
이후에 기획에서 수정을 많이 거쳤다. 이후 테이블과 테이블 별로 컬럼이 많이 수정되었다. ERD Cloud를 이용하여 DB를 짜보았다.
ERD Cloud 캡처본
짜면서 다시 DB의 관계를 생각할 수 있게 되었다. 다행히 이전에 DB 짜던 감을 잃지 않았다! 생각한 그대로 나왔고, 그 과정에서 화살표의 의미를 다시 이해할 수 있었다.
💬 느낀 점
아직 DB 짜는 감을 잃진 않았구나! 싶었다. 하지만 관계는 얼추 맞았지만, 타입을 지정하는 방식이나 크기를 지정하는 점 등등에서 부족한 점이 느껴졌다. SQLD 자격증을 취득하는 걸 고려하게 되었다.
이제 Entity 들어가고, DTO 작성하게 될 텐데 그 전에 공부해둘 것이 많다.
📚 참고자료
