공부할 때 기록하는 게 좋은데, 그대로 쓰기보단 내가 이해하기 쉽게 바꿔서 정리하거나 요약하는 게 좋다. 글의 완성도는 중요하지 않다. 강의 이미지 캡쳐해도 된다.

개발 분야를 공부할 땐 1부터 100까지 다 공부한다는 느낌이 아니라 자주 쓰는 20% 정도만 확실하게 익혀야겠다는 마인드로 공부해야 한다. 자주 사용하는 20% 정도만 익혀도 서비스를 운영하는 데 큰 문제없다. 나머지 80% 지식은 필요할 때 찾아서 공부하면 된다.

완벽주의를 가진 사람은 처음부터 끝까지 개념과 작동 과정을 다 이해한 뒤에 실전에서 써먹어 보려고 한다. 그러면 늦는다.

중요하고 자주 사용되는 기능을 우선적으로 익히고 바로 실전에 적용시켜 봐야 한다. 그래야 실력이 빨리 는다.

테이블명, 컬럼명은 소문자로 작성하는 게 좋다. MySQL에서는 운영체제에 따라 대소문자를 구분하기도 하고 구분 안 하기도 한다. 그래서 대소문자를 섞어서 쓰면 운영체제에 따라 잘 되기도 하고, 잘 안 되기도 한다.

최근 트렌드는 변수명이 길어지더라도 가독성이 더 중요하다.

예약어는 운영체제랑 상관없이 대소문자를 구분하지 않는 듯(ChatGPT)

데이터베이스 네이밍 규칙)

1. 테이블명, 컬럼명을 소문자로 작성한다.

2. snake_case를 사용한다.

3. 축약어를 사용하지 않는다.

4. SQL문을 작성할 때 예약어만 대문자로 작성한다.

5. 테이블명을 지을 땐 복수형으로 작성한다. 그렇지 않다 해도 일관성 있게 작성하면 된다.

엄격하게 지켜야 하는 건 아닌 듯

이상 현상의 개념이 일부 쓰이기는 하는데 용어의 정의를 정확히 기억할 필요는 없다.

정규화도 일부 필요한 부분만 알면 될 듯

다만 평생 배우지 말라는 건 아니고, 당장 DB 설계에만 필요 없다는 것이다.

DB 설계의 핵심은 ‘중복 없애기’이다.

데이터 중복으로 인해 발생할 수 있는 문제가 이상 현상이고, 이상 현상을 해결하기 위해 정규화라는 과정을 거친다.

DB를 설계하면서 중복을 없애는 과정이 바로 정규화다.

면접용) 데이터베이스 설계할 때 어떤 걸 고려해서 설계해야 하나?

RDBMS에서 데이터 모델링을 할 때는 정규화를 통해 데이터 중복을 최소화할 수 있게 설계해야 합니다. 그래야 삽입 이상, 수정 이상, 삭제 이상과 같은 이상 현상을 방지할 수 있으며 데이터 무결성을 지킬 수 있습니다.

서비스 기획을 먼저 하고, 그 기획을 바탕으로 디자인을 하고, 그다음에 개발에 들어간다.

그러면 그 디자인을 보고 저장해야 할 데이터를 추출한다.

그룹핑하는 건 인간이라면 알아서 잘 할 수 있다.

그런데 사람마다 좀 다르게 분류할 수도 있다. 그래도 6가지 규칙을 적용시키면서 테이블을 분리해 나가면 결국 똑같은 모양이 된다.

그러니 일단 분류해 보고, 구성된 테이블에서 규칙에 맞게 조금씩 변형하면 된다.

데이터를 저장해야 하는지 안 해야 하는지 판단 방법은 언젠가 이 데이터를 꺼내 쓸 일(조회)이 있을 것 같다는 생각이 들면 저장하면 된다.

최근엔 전화번호를 통째로 저장하는 경우가 많지만, 예전엔 따로 구분해서 저장하는 경우도 많았다.

내 서비스에서 따로따로 조회할 일이 있는지, 아니면 통째로 조회해도 되는지에 따라 다르다.

만약 처음에 설계할 땐 성과 이름을 합쳐서 하나의 정보로 했었는데, 만약 기획자가 성과 이름을 분리하는 거로 바꾸자고 한다면? 데이터베이스 설계도 같이 바꿔 줘야 한다.

즉, 데이터베이스 설계는 처음 한 대로 끝까지 가는 게 아니라, 기획이나 상황에 따라 그때그때 변경될 수 있다.

규칙 1 요약)

• 한 칸에는 한 가지 정보만 들어가야 한다.

• 한 칸에 두 가지 이상의 정보가 들어가 있을 땐, 테이블을 분리해서 FK를 활용하면 된다.

• 특정 테이블에 FK를 도입했을 때 규칙 1이 안 지켜진다면, 다른 테이블로 FK를 옮겨 보자.

• ‘한 가지 정보’의 기준은 절대적이지 않다. 따라서 서비스에 맞게 판단해야 한다.

가운데 테이블의 이름을 어떻게 지을까?

students 테이블과 courses 테이블을 합쳐서 students_courses라고 하는 경우가 많다. 이렇게 해도 괜찮긴 한데, 좀 더 의미 있게 잘 붙이려면 students와 courses의 관계를 표현해 주는 동사를 적어 주면 좋다. 예를 들면 course_registrations

movies 테이블과 actors 테이블로 인해 새로 테이블을 만들 때 movies_actors라고 하거나

영화는 배우를 ~~한다.를 생각해 보면, 즉 어울리는 동사를 생각해 보면 캐스팅이 어울린다. castings

규칙 2 요약)

• 어떤 테이블에 FK를 넣어도 ‘규칙 1’을 못 지킬 때는 중간 테이블을 하나 더 만들어라.

• 중간 테이블에 두 테이블의 FK가 들어가야 한다.(두 테이블의 PK를 가져와서 각각 FK로 한다는 뜻인 듯)

규칙 1이랑 규칙 2가 헷갈릴 때 즉, 중간 테이블을 언제 만들지, 언제 안 만들지 FK 관련 등등이 헷갈릴 때가 있을 것이다.

그걸 다른 방법으로도 구분하는 방법이 규칙 3이다.

하나의 판매 상품은 한 가게에 의해 팔릴까? 여러 가게에 의해 팔릴까? 서비스마다 다를 수 있다.

예를 들어 물은 여러 가게에 있을 수 있다. 공동의 상품을 여러 가게에서 파는 서비스라면 하나의 판매 상품이 여러 가게에 의해 팔린다가 맞다.

서비스에 따라선 하나의 판매 상품이 하나의 가게에 의해 팔린다가 맞다.

서비스마다 다르므로 서비스 기획자에게 물어봐야 한다.

사용자와 이메일로 테이블을 분리할 때, 규칙 1과 규칙 2로만 판단해도 됐었지만, 좀 헷갈리면 지금의 규칙 3으로 판단하면 된다.

이전엔 FK를 사용자 테이블에 넣었다가 안 되니깐 이메일 테이블에 넣었었는데, 규칙 3대로 관계를 파악하니깐 FK가 무조건 이메일 테이블에 들어가야 한다는 걸 알 수 있다.

이게 관계를 파악했을 때의 장점이다.

N:M 관계의 특징은 FK의 위치가 새로운 테이블에 다 배치된다.

규칙 1, 2에서 했던 대로 FK를 직접 두 테이블에 각각 넣어 보는 방식으로 확인을 안 하고, 바로 규칙 3으로 관계를 파악해도 된다.

규칙 3의 관계 파악이 무조건 간단한 것도 아니다. 때로는 규칙 1, 2로 하는 게 나을 때도 있다. 즉, FK를 A 테이블에도 넣어 보고, B 테이블에도 넣어 보는 식으로 판단하게 될 때도 있다.

1:1 관계는 하나의 테이블로 표현하는 게 더 간단한지 체크해 보자. 그래도 분리하는 게 데이터를 관리함에 있어서 더 편하다면 분리하면 된다.

어지간하면 1:1 관계로 분리하지 않는 걸 추천한다. 테이블을 쪼개면 나중에 데이터를 불러올 때 조인해서 부르는 등 불편한 점이 있다. 분리해서 엄청 편해지는 게 아니라면 합치는 게 나을 것이다.

DB 설계할 때는 1:1 관계가 생각보다 잘 안 나온다. 나오더라도 그냥 합치는 경우가 많다.

데이터베이스 개론 책 내용)

일반적인 일대일 관계의 경우 두 개체 중 아무 한쪽에만 외래키와 관계의 속성을 넣으면 되고,

만약 A 개체는 관계에 선택적으로 참여하고, B 개체는 관계에 필수적으로 참여한다면, B 개체에 A 개체의 기본키를 받아 외래키로 지정하고, 관계의 속성들도 B 개체에 넣는다. 외래키를 A 개체에 넣는다고 해도 관계를 표현하는 데 문제는 없다. 다만 이러면 외래키에 널 값이 저장되는 경우가 많을 것이다. 그래서 B 개체에 넣는 것이 낫다.

규칙 3 요약)

• 규칙 1이랑 규칙 2로 파악하기 힘들면 규칙 3으로 파악하면 된다. 또는 규칙 3으로 힘들면 규칙 1, 2로 파악할 수도 있다.

• 엔터티 관계를 파악하기 위해 우선 엔터티 간 어울리는 동사를 찾고, 두 엔터티 각각에 '하나의' or '여러 개의'를 붙여서 관계를 파악하라.

• 1:N 관계의 특징이면 N 쪽 테이블에 FK가 들어가야 한다.

• N:M 관계의 특징이면 중간 테이블이 있어야 하고, 중간 테이블에 두 테이블의 FK가 들어가야 한다.

• 1:1 관계의 특징이면 아무 테이블에 FK를 넣어도 된다. 분리하는 게 더 나은 게 아니라면 웬만하면 합치는 게 낫다.

• (데이터베이스 개론 책 내용) A 개체는 관계에 선택적으로 참여하고, B 개체는 관계에 필수적으로 참여한다면, B 개체에 외래키와 관계의 속성들을 넣는 게 더 낫다.

FK의 중복은 중복이라고 판단하지 않는다. 중복의 문제점은 박재성이라는 이름을 고칠 때 실수로 하나를 놓칠 때 발생한다. 근데 지금은 users 테이블에서 id = 1에 해당하는 튜플에서 이름을 박재성에서 박지성으로만 고치면 되니까 posts 테이블의 작성자 id FK엔 영향이 안 간다.

규칙 4 요약)

• 임의의 데이터들을 넣어서 데이터 중복이 발생하는지 확인하라

• 만약 중복이 발생하면 테이블을 분리하고, FK를 활용하라.

가짜 중복인지 진짜 중복인지 판단하려면 이렇게 질문해 보면 된다.

“실제 서비스에서 A 데이터의 값을 수정하면, B 데이터의 값도 같이 수정되어야 하는가?”

서비스마다 달라서 데이터베이스 설계가 다를 수 있다.

쿠팡 같이 다양한 업체가 들어와서 물건을 판매하는 서비스라고 생각해 보자.

products(상품) 테이블에서 상품명은 판매자가 이름을 붙이기 나름이라서, 같은 이름이 있을 수 있다고 하자. 이건 중복일까? 가짜 중복이다. 우연히 이름이 같을 뿐 별개의 상품이다.

다만 서비스마다 다를 수 있다. 카테고리가 각 상품마다 독립적으로 가지고 있는 카테고리 이름인지, 아니면 하나의 카테고리에 다 들어가 있는 상품인지 등을 물어봐야 한다. 하나의 카테고리에 다 똑같이 들어가 있는 상품이면 진짜 중복이다.

규칙 5 요약)

• 가짜 중복인지 진짜 중복인지 구별하라.

• 구별 방법은 다음을 따져 봐라. “실제 서비스에서 A 데이터의 값을 수정하면, B 데이터의 값도 같이 수정되어야 하는가?” -> 수정되어야 하면 진짜 중복이다. 아니면 가짜 중복이다.

• 진짜 중복의 컬럼에 대해서만 테이블을 분리하라. 물론 FK를 활용하면 된다.

완성된 테이블 기준으로 1번 게시글의 좋아요 수를 알고 싶으면, 좋아요 테이블을 기준으로 게시글 id 1번으로 쭉 필터링을 해서 개수를 세면 된다. 그게 좋아요 수다.

이런 식으로 좋아요 수를 계산할 수 있기 때문에, 게시글 테이블에 굳이 좋아요 수 컬럼을 넣지는 않는다.

그런데 회사에 따라서 게시글 테이블에 좋아요 수를 넣기도 한다. 데이터 중복 허용했다.

역정규화라는 방식이 있다. 데이터 중복을 허용하면서 나름의 어떤 편리함을 가져가는 거다. 트레이드오프를 가져가는 거다.

근데 일단 이건 배우지 말자. 정석적인 방법이 처음엔 아니다.

중복을 없앤 채로 설계하는 방식을 먼저 배우고 성능 등 뭔가에 문제가 생기면 그때 추가하는 건데 입문자는 아직 건들지 않는 게 좋다.

규칙 6 요약)

• 숨어 있는 중복을 찾아라. 특정 데이터를 수정할 때, 다른 데이터도 같이 수정해 주어야 하는 상황이 마찬가지로 생긴다.

• 숨어 있는 중복은 게시글 테이블의 '좋아요 수' 컬럼처럼 겉으로 봤을 땐 중복이 아닌 것 같지만, 무언가를 수정할 때 같이 수정해야 하는 경우를 말한다.

• 숨어 있는 중복은 주로 집계(합계, 평균, 최댓값 등)의 값에서 많이 나타난다.(예제의 경우 게시글 테이블의 좋아요 수)

• 이 예시의 경우, 숨은 데이터 중복이 발생하지 않게 하려면 게시글 테이블에서 '좋아요 수' 컬럼을 없애면 된다.

이 데이터를 나중에 조회해서 쓸 일이 있겠다 싶은 것들은 전부 저장해야 한다.

분류는 사람마다 조금 다를 수 있다. 6가지 규칙 적용시키다 보면 결과는 똑같이 나온다. 그러니 일단 대략적으로 분류해 보자.

팔로우 수, 누가 팔로우를 했는지, 누가 팔로우를 받았는지도 그냥 사용자 테이블에 그룹핑해도 된다. 어차피 6가지 규칙 적용하면 분리된다.

저장할 데이터 고르고, 분류도 해서 테이블 초안을 만들었다면, 이제 임의의 데이터를 넣어 봐야 한다.

데이터 중복이 발생하는지 안 하는지, 한 칸에 한 가지 정보만 들어가는지 확인할 것이다.

어거지로 중복을 만들어서 넣어 보자.

규칙 1에 문제가 없기 때문에 규칙 2는 판단할 필요가 없다.

게시글 테이블을 설계할 때

id, 제목, 내용, 해시태그, 카테고리, 작성자, 작성 시간, 좋아요 수, 누가 좋아요 눌렀는지, 어떤 게시글에 좋아요 눌렀는지, 조회 수

이렇게 했더라도 6가지 규칙 적용하면서 확인할 때 '어떤 게시글에 좋아요 눌렀는지'에 대한 컬럼은 필요 없다는 걸 확인해서 지웠다.

게시글 테이블에서 카테고리 테이블을 분리할 때 규칙 4로 했지만, FK를 어디 둘지 생각할 땐 규칙 3의 관계를 파악했다.

게시글 테이블에서 작성자 컬럼에 중복이 발생한다. 작성자 테이블을 따로 분리해야 하는데 이미 사용자 테이블이 있다. 그래서 그냥 여기에 사용자 테이블의 PK를 가져와서 FK로 쓰면 된다.

신고 사유는 직접 적는 경우가 있고, 객관식처럼 선택하는 경우가 있다. 이에 따라 다른데 지금은 직접 적는 경우라고 가정한다.

게시글 테이블에 '조회 수' 컬럼은 그대로 둬도 되나? 괜찮기도 한다.

그대로 둘 때의 단점이 있다. 누가 조회를 했는지 정보를 알 수 없다. 이걸 모르면 특정 사용자가 새로 고침을 누를 때마다 조회 수가 계속 오른다. 하지만 어떤 사용자가 조회했는지 기록하면 중복 조회를 거를 수 있다.

그래서 조회 수는 보통 숫자로만 잘 표현하지 않고, 어떤 사용자가 어떤 게시글을 조회했는지 정보를 같이 남긴다.

이걸 눈치챌 수 있는 건 설계 경험이 좀 필요하다.

혹시나 처음부터 데이터베이스 설계를 완벽하게 하지 못하더라도 즉, 중복을 놓친다고 하더라도 나중에 임의의 데이터를 넣으면서 테스트를 하면서 데이터베이스를 까 보면 데이터가 중복되어 쌓여 있는 걸 보고 내가 설계를 제대로 안 한 건지 찾고 그때 분리하는 경우도 있다.

저장할 데이터 고르고 분류한 후(6가지 규칙 적용 전)

• 사용자 테이블: id, 이메일, 비밀번호, 이름, 나이

• 게시글 테이블: id, 제목, 내용, 해시태그, 카테고리, 작성자, 작성 시간, 좋아요 수, 누가 좋아요 눌렀는지, 어떤 게시글에 좋아요 눌렀는지, 조회 수

• 팔로우 테이블: id, 팔로우 수, 팔로우 누른 사람, 팔로우 받은 사람

• 신고 테이블: id, 신고한 사람, 신고된 게시글, 신고 사유

최종 결과)

• 사용자 테이블: id, 이메일, 비밀번호, 이름, 나이

• 게시글 테이블: id, 제목, 내용, 카테고리 id(FK), 작성자 id(FK), 작성 시간

• 조회 수 테이블: id, 누가 조회했는지 id(사용자 FK), 어떤 게시글을 조회했는지 id(게시글 FK)

• 좋아요 테이블: id, 좋아요 누른 사람 id(사용자 FK), 게시글 id(게시글 FK)

• 카테고리 테이블: id, 카테고리명

• 해시태그 테이블: id, 이름

• 게시글-해시태그 테이블: id, 게시글 id(게시글 FK), 해시태그 id(해시태그 FK)

• 팔로우 테이블: id, 팔로우한 사람 id(사용자 FK), 팔로우된 사람 id(사용자 FK)

• 신고 테이블: id, 신고자 id(사용자 FK), 신고 사유, 신고된 게시글 id(게시글 FK)

한 주문에 어떤 상품이 담겼는지, 주문할 때 각 상품의 수량, 주문할 때 각 상품의 가격, 주문했을 때 총 상품들 가격, 주문한 사용자, 배송 정보 이름, 배송 정보 주소, 배송 정보 전화번호, 주문한 날짜

여기서 배송 정보 이름, 배송 정보 주소, 배송 정보 전화번호는 분리해서 관리해도 된다. 안 해도 되는 듯

사용자의 이름, 주소, 전화번호랑 배송 정보의 이름, 주소, 전화번호랑 다르게 설정할 수 있다.

상품의 총 가격 컬럼은 숨은 중복이다.

주문 상품 테이블은 이미 주문한 상품이다.

주문 상품 테이블의 '주문할 때 각 상품의 가격'과 상품 테이블의 '가격'은 진짜 중복일까? 아니다. 가짜 중복이다.

이미 1000원에 주문한 상품이 나중에 가격이 바뀔 수도 있지만, 주문서에 적힌 가격은 그대로다. 그러므로 따로따로 기재하는 게 맞다.

서비스마다 다를 수 있지만 배송 정보(이름, 주소, 전화번호)는 주문할 때마다 기록한다.

어떤 주문을 할 때 어떤 배송 정보를 입력했는지까지 알아야 한다.

아직 FK를 넣지 않아서 FK를 추가해야 한다.

(하나의 주문 정보는 하나의 배송 정보만 가진다고 가정했다.)

(배송 정보는 매번 주문할 때마다 따로 입력한다고 가정한다.)

주문 정보 : 배송 정보 = 1:1

1:1 관계이므로 FK를 배송 정보 테이블에 넣든, 주문 정보 테이블에 넣든 상관없다.

1:1 관계이므로 두 테이블을 합쳐도 되나?

배송지에 대한 정보를 따로 조회할 일이 많고, 주문 정보에 대해 따로 조회할 일이 많다면 테이블을 분리하는 게 낫다. 만약 통째로 조회할 일이 많다면 테이블 하나에 넣는 게 더 나을 수도 있다.

배송 정보에서 이름이나 주소, 전화번호는 중복일까? 아니다. 배송 정보는 그때그때 직접 기입하는 거다. 가짜 중복이다.

리뷰 테이블의 리뷰 평점은 가짜 중복이다.

리뷰 테이블의 '어떤 상품에 리뷰를 달았는지'는 진짜 중복이다. 만약 상품 테이블에서 상품명을 바꾸면 '어떤 상품에 리뷰를 달았는지'도 바뀌어야 한다. 다만 같은 사람이 같은 상품에 또 리뷰를 달지 못하는 듯

저장할 데이터 고르고 분류한 후(6가지 규칙 적용 전)

• 사용자: id, 이메일, 비밀번호, 이름, 주소, 전화번호

• 상품: id, 상품명, 설명, 가격, 재고량, 카테고리, 등록 시간, 등록한 사람

• 주문: id, 한 주문에 어떤 상품이 담겨있는지, 주문할 때 각 상품 수량, 주문할 때 각 상품 가격, 주문했을 때 총 상품들 가격, 주문한 사용자, 주문한 날짜

• 배송 정보: id, 이름, 주소, 전화번호

• 리뷰: id, 리뷰 작성한 사람, 리뷰 내용, 리뷰 평점, 어떤 상품에 리뷰를 달았는지

• 관리자: id, 이메일, 비밀번호

최종 결과)

• 사용자: id, 이메일, 비밀번호, 이름, 주소, 전화번호

• 상품: id, 상품명, 설명, 가격, 재고량, 카테고리 id(FK), 등록 시간, 등록한 사람 id(사용자 FK)

• 상품 카테고리: id, 카테고리명

• 주문 정보: id, 주문한 사용자 id(FK), 주문한 날짜, 배송 id(FK)

• 주문 상품: id, 주문 id(FK), 상품 id(FK), 주문 수량, 주문할 때 각 상품의 가격

• 배송 정보: id, 이름, 주소, 전화번호

• 리뷰: id, 리뷰 작성자 id(사용자 FK), 리뷰 내용, 리뷰 평점, 어떤 상품에 리뷰를 달았는지 id(상품 FK)

• 관리자: id, 이메일, 전화번호

툴은 다양하지만 최근 현업에서 유행하는 디자인 툴은 Figma이다. 디자이너들이 많이 쓴다.

저장해야 하는 데이터를 쭉 모으고 그룹핑을 하고 6가지 규칙 적용시켰었는데, 이번엔 바로 엑셀에 옮겨서 하나씩 하나씩 데이터를 붙이는 식으로 세팅해 보겠다.

사용자라는 테이블에 저장해야 할 것 같단 생각이 든다. 저장할 데이터 찾기 + 그룹핑을 같이 하자. 엑셀에 바로 입력해 보자.

users(사용자): id, 사용자 이름, 이메일, 패스워드

이메일이랑 패스워드는 이미 기록했으니 넘어간다.

작성자 정보에 프로필 이미지가 있다. 이것도 위에 작성한 사용자 테이블에 추가한다. 다시 보니 사용자 이름이 아니라 사용자 닉네임 같다.

users(사용자): id, 닉네임, 이메일, 패스워드, 프로필 이미지

글 아래에 날짜가 있는데 이게 무엇인지 기획자나 디자이너한테 물어보자. 게시글 작성 날짜라고 하자.

posts(게시글): id, 작성 날짜, 제목, 내용, 해시태그, 좋아요 수

오른쪽 위에 jscode123이라고 적혀 있는데 잘 모르겠으면 기획자한테 물어보자. 회원 가입 때 쓴 username이면 추가적으로 저장할 정보는 없다.

그리고 Popular Tags를 보면 인기 있는 태그를 선별해서 보여 줘야 한다는 걸 알 수 있다. 게시글들에서 많이 쓰인 태그 순서대로 보여 줘야 한다고 하자.

hashtags(해시태그): id, 태그명, 게시글에서 사용된 횟수

Your Feed를 보면 내 게시글인지 아닌지 파악할 수 있어야 하는 것 같다. 게시글 테이블의 작성자와 로그인한 아이디가 일치하는지 체크해서 쭉 조회하면 된다. 그러므로 작성자 컬럼을 추가한다.

posts(게시글): id, 작성 날짜, 제목, 내용, 해시태그, 좋아요 수, 작성자

이런 식으로 계속 보완해 나가야 한다.

What's this article about?이 뭔지 물어봐야 한다. 게시글 소제목이라는 답변을 들었다고 하자. 이것도 추가하자.

posts(게시글): id, 작성 날짜, 제목, 소제목, 내용, 해시태그, 좋아요 수, 작성자

이 화면은 특정 해시태그를 클릭했을 때, 그 해시태그를 기준으로 게시글을 조회하는 기능인 듯하다. 특정 해시태그를 기준으로 게시글을 쭉 조회하면 된다. 추가적으로 저장할 데이터는 없어 보인다.

이 페이지는 특정 게시글을 클릭했을 때 나오는 게시글 상세 페이지다. 잘 보면 팔로우 기능이 있다.

follows(팔로우): id, 팔로우한 사람, 팔로우를 받은 사람

Favorite Article(4)을 보면 좋아요 수가 몇 개인지뿐만 아니라, 내가 좋아요를 누른 상태인지 아닌지 알려면, 누가 어떤 게시글에 좋아요를 눌렀는지도 알아야 한다. 아직까진 게시글 테이블에 좋아요 수 컬럼만 넣었고, 좋아요를 누가 어떤 게시글에 눌렀는지는 없기 때문에 그 내용을 추가하겠다.

likes(좋아요): id, 좋아요를 누른 사람, 좋아요를 누른 게시글

댓글 내용과 댓글 작성자와 댓글 작성 날짜가 있다.

comments(댓글): id, 내용, 작성자, 작성 시간, 어떤 게시글 댓글인지

마이 페이지를 보니 프로필 사진의 URL을 넣을 수 있다.

이전에

users(사용자): id, 닉네임, 이메일, 패스워드, 프로필 이미지

이렇게 저장한 걸

users(사용자): id, 닉네임, 이메일, 패스워드, 프로필 이미지 URL

이렇게 구체적으로 수정하자.

Short bio about you를 보니 자기소개 같다. 이것도 추가하자.

users(사용자): id, 닉네임, 이메일, 패스워드, 프로필 이미지 URL, 자기소개

내 게시글을 조회할 수 있는 기능 같다. 이미 반영했던 내용들이다.

좋아요를 눌렀던 게시글을 조회하는 건, 내가 어떤 글에 좋아요를 눌렀는지 파악할 수 있는 구조로 설계가 되어 있는지를 확인해 보자. 좋아요 테이블에서 확인할 수 있다. 그냥 넘어가면 된다.

지금까지 테이블 초안을 작성했다.

이제 임의의 데이터를 넣어 보고 중복된 데이터가 발생하는지 확인해 보자.

사용자 테이블의 닉네임과 이메일은 중복이 발생할 수 없게 기획됐다고 하자. 그럼 신경 쓸 필요 없다.

패스워드는 가짜 중복이다.

프로필 이미지 URL도 우연히 같은 URL로 겹칠 수 있지만 가짜 중복이다.

자기소개도 가짜 중복이다.

사용자 테이블은 수정할 게 없다.

게시글 테이블의 작성 날짜, 제목, 소제목, 내용은 가짜 중복이다.

게시글 테이블의 해시태그엔 여러 값이 들어갈 수 있다.

예) 생활, 꿀팁, 자유

해시태그는 테이블 분리해야 한다. 그런데 이미 해시태그 테이블을 만들어 놨다. 그런데 게시글 테이블에 해시태그 id를 넣어도 여전히 다중 값이 들어간다. 해시태그 테이블에 게시글 id를 넣어도 마찬가지다.

중간 테이블을 만들어야 한다. N:M 관계다.

posts_hashtags: id, post_id(FK), hashtag_id(FK)

그리고 게시글 테이블에서 해시태그 컬럼은 지우면 된다.

좋아요 수 컬럼은 숨어 있는 중복이다. 좋아요 테이블에서 좋아요 수를 계산할 수 있다. 그러므로 게시글 테이블의 좋아요 수 컬럼을 지운다.

작성자 컬럼은 진짜 중복이다. 작성자 id(사용자 FK)로 수정한다. 사용자 테이블은 이미 분리를 해 놨었다.

다음과 같이 완료됐다.

posts(게시글): id, 작성 날짜, 제목, 소제목, 내용, 작성자 id(사용자 FK)

해시태그 테이블을 다시 보자.

hashtags(해시태그): id, 태그명, 게시글에서 사용된 횟수

게시글에서 사용된 횟수는 집계한 숫자이다. 통계치가 있는 컬럼은 숨은 중복일 가능성이 높다. 다른 곳에서 게시글에서 사용된 횟수를 체크할 수 있는지 확인해 보자.

posts_hashtags 테이블에서 필터링을 하고 개수를 세면 된다. 그리고 posts_hashtags 테이블에서 튜플 하나를 지우면 hashtags 테이블의 '게시글에서 사용된 횟수' 컬럼도 수정해야 한다. 즉, 숨어 있는 중복이다.

hashtags 테이블의 '게시글에서 사용된 횟수' 컬럼은 삭제하면 된다.

다음과 같이 완료했다.

hashtags: id, 태그명

follows: id, 팔로우한 사람, 팔로우를 받은 사람

FK를 활용하자.

사용자에 대한 정보는 사용자 테이블에 이미 만들어 뒀다.

이렇게 두면 된다.

follows: id, 팔로우한 사람 id(사용자 FK), 팔로우를 받은 사람 id(사용자 FK)

likes: id, 좋아요를 누른 사람, 좋아요를 누른 게시글

좋아요 테이블을 보면 FK를 활용하면 된다.

이렇게 두면 된다.

likes: id, 좋아요를 누른 사람 id(사용자 FK), 좋아요를 누른 게시글 id(게시글 FK)

comments(댓글): id, 내용, 작성자, 작성 시간, 어떤 게시글 댓글인지

내용은 가짜 중복이다.

작성자는 사용자 FK를 사용하면 된다.

작성 시간도 가짜 중복이다.

어떤 게시글 댓글인지는 게시글 FK를 사용하면 된다.

다음처럼 두면 된다.

comments(댓글): id, 내용, 작성자 id(사용자 FK), 작성 시간, 어떤 게시글 댓글인지 id(게시글 FK)

테이블 초안)

• users(사용자): id, 닉네임, 이메일, 패스워드, 프로필 이미지 URL, 자기소개

• posts(게시글): id, 작성 날짜, 제목, 소제목, 내용, 해시태그, 좋아요 수, 작성자

• hashtags(해시태그): id, 태그명, 게시글에서 사용된 횟수

• follows(팔로우): id, 팔로우한 사람, 팔로우를 받은 사람

• likes(좋아요): id, 좋아요를 누른 사람, 좋아요를 누른 게시글

• comments(댓글): id, 내용, 작성자, 작성 시간, 어떤 게시글 댓글인지

최종 결과)

• users(사용자): id, 닉네임, 이메일, 패스워드, 프로필 이미지 URL, 자기소개

• posts(게시글): id, 작성 날짜, 제목, 소제목, 내용, 작성자 id(사용자 FK)

• hashtags(해시태그): id, 태그명

• posts_hashtags(게시글 해시태그): id, post_id(FK), hashtag_id(FK)

• follows(팔로우): id, 팔로우한 사람 id(사용자 FK), 팔로우를 받은 사람 id(사용자 FK)

• likes(좋아요): id, 좋아요를 누른 사람 id(사용자 FK), 좋아요를 누른 게시글 id(게시글 FK)

• comments(댓글): id, 내용, 작성자 id(사용자 FK), 작성 시간, 어떤 게시글 댓글인지 id(게시글 FK)

실무에서도 이런 식으로 설계한다. 이렇게 하고 실제 코드 구현하면 된다.

이번에도 데이터베이스 설계를 엑셀에 바로 해 보자.

저장해야 하는 데이터를 파악하면서 그룹핑도 동시에 하자.

여길 봤을 때 저장할 데이터가 없다고 느껴지면 그냥 패스하면 된다.

username과 password가 필요해 보인다.

users(사용자): id, 계정, 패스워드

(이해하기 쉽도록 지금은 한글로 썼다.)

비밀번호 확인이 있긴 하지만 이전에 적은 거로 충분하다.

Add Task를 통해 할 일을 추가할 수 있는 것 같다.

할 일의 제목을 쓸 수 있는 것 같고, 설명을 쓸 수 있는 것 같다.

tasks(임무): id, 제목, 설명

4, 5번째 화면을 보면 날짜랑 시간도 선택할 수 있다.

tasks(임무): id, 제목, 설명, 마감 날짜

6번째 화면은 아까 본 화면인 듯

7번째 화면은 우선순위를 매길 수 있다.

tasks(임무): id, 제목, 설명, 마감 날짜, 우선순위

8번째 화면을 보면 Completed라고 써진 걸 보니 완료 여부를 체크할 수 있는 것 같다.

tasks(임무): id, 제목, 설명, 마감 날짜, 우선순위, 완료 여부(true: 완료 / false: 완료 X)

완료 여부를 이렇게 표현할 수 있다고 결정했다고 치자

University 같은 태그처럼 보이는 걸 붙일 수 있다. 기획자에게 물어보니 카테고리 같은 거라고 말했다고 치자.

tasks(임무): id, 제목, 설명, 마감 날짜, 우선순위, 완료 여부(true: 완료 / false: 완료 X), 카테고리

카테고리를 추가할 수 있고 카테고리 이름, 아이콘, 색을 저장할 수 있다.

categories(카테고리): id, 이름, 아이콘, 색깔

아이콘은 아이콘 이미지가 저장된 URL 주소일 수도 있고, 아니면 앱 자체에 들어 있는 아이콘 고유한 값일 수도 있다. 그걸 데이터베이스에 저장했다가 앱에게 알려 주는 형태로 쓰기도 한다. 우리는 아이콘의 고유한 코드 값으로 쓴다고 가정하겠다. 예를 들면 HOME 같은 키워드 값으로 표현한다고 치자.

임무에 대해 보여 주는 창인 듯하다.

이전에 적은 tasks를 보면 제목, 설명, 마감 날짜, 카테고리, 우선순위 등을 적었었다. 우선순위에 Default로 설정할 수 있는 것 같다. 서브 태스크도 추가할 수 있는 듯하다. 서브 태스크는 어떻게 추가하는지 디테일한 화면이 안 나왔으니 이 부분은 잠깐 보류해 두자.

태스크 제목과 내용, 아이콘, 우선순위 마감 날짜를 수정할 수 있다.

태스크 삭제도 된다.

서브 태스크는 그냥 기능 구현 안 한다고 생각하겠다. DB 설계하기에 디자인이 완벽하지 않아서 그냥 없다 생각하고 설계하자.

캘린더를 보면 날짜별로 내가 해야 하는 임무들을 쭉 볼 수 있다. Today와 Completed로 되어 있는 걸 봐선 완료 안 된 것과 완료된 것을 볼 수 있는 거로 보인다. 자세한 건 기획자나 디자이너에게 물어보는 게 낫다.

이걸 다 표현할 수 있게 이미 tasks 테이블에 완료 여부 컬럼, 카테고리 컬럼, 마감 날짜 컬럼, 우선순위 컬럼이 있기 때문에 날짜별로 각 태스크들을 조회할 수 있다.

나머지 화면들도 이전에 다 저장한 데이터들이다.

Focus Mode는 내가 하루 동안 집중한 시간들을 통계를 내는 기능으로 보인다.

측정을 start 했다가 stop 했다가 start 했다가 반복할 수 있다. 그럼 이 수치는 하루 동안 내가 포커스를 한 시간들의 합계를 나타내야 하는 통계 그래프다.

이걸 어떻게 우리가 남겨야 할까? 우선 우리가 포커스 모드를 어떤 시점부터 얼마나 집중을 했는지 시간을 세야 한다.

focus_histories(집중 시간 히스토리): id, 시작 시간, 종료 시간

종료 시간과 시작 시간의 차이를 계산하면 얼마나 집중했는지 알 수 있다. 아니면

focus_histories(집중 시간 히스토리): id, 집중한 시간

이렇게 해도 괜찮다.

날짜별로 총 집중한 시간을 알아야 하니 기록 날짜를 적어야 한다.

focus_histories(집중 시간 히스토리): id, 시작 시간, 종료 시간, 기록 날짜

또는

focus_histories(집중 시간 히스토리): id, 집중한 시간, 기록 날짜

이렇게 하면 된다. 우리는 좀 더 편하게 하기 위해 두 번째 것으로 하겠다.

Applications에 대한 정보가 나오는데 이걸 프론트 단에서 이 데이터 정보를 미리 넣어 놓고 이렇게 세팅해 놓을 수 있다. 하지만 매번 이렇게 바뀌는 정보라면 데이터베이스에 인스타그램, 트위터, 페이스북, 텔레그램, 지메일 같은 정보를 관리할 수도 있지만, 자주 안 바뀌는 정보에 대해선 데이터베이스에서 데이터를 직접 저장해 두고 조회하지 않고, 프론트(앱) 단 자체에서 이 데이터 정보를 그냥 고정적으로 넣어 놓을 수 있다. 그래서 데이터베이스에 저장하는 데이터라고 보지 않고 프론트 단에서 처리할 거라고 생각하겠다.

그러면 데이터베이스에 저장해야 할까 안 해야 할까?는, 이 정보들이 자주 바뀌는 정보면 데이터베이스에 저장해 놓고 프론트 단에서 백엔드로 저 데이터를 받아 와서 그때그때 실시간으로 업데이트 시키는 게 훨씬 낫다.

그게 아니라면 프론트 입장에서 직접 저걸 고정적으로 넣어 놓는 게 낫다.

이걸 어떻게 판단해야 하냐면 기획자랑 프론트 개발자랑 백엔드 개발자랑 같이 소통하면서 이것들을 DB에 저장해서 보여 주는 식으로 할지, 아니면 프론트 단에서 고정으로 만들어 놓을지를 물어봐야 한다. 회의를 해서 결정해야 한다.

유저 프로필에 이미지 사진이 있다. 사용자 테이블에 추가한다.

users(사용자): id, 계정, 패스워드, 프로필 사진

몇 개의 태스크가 남았고 몇 개의 태스크를 완료했는지는 개수를 따로 기록하지 않더라도 tasks 테이블에서 체크할 수 있다.

그런데 여기서 특정 사용자의 임무 개수를 알아야 하니, 각 태스크가 어떤 사용자의 임무인지를 알아야 한다. 사용자 id 컬럼을 추가하겠다.

tasks(임무): id, 제목, 설명, 마감 날짜, 우선순위, 완료 여부(true: 완료 / false: 완료 X), 카테고리, 사용자 id(FK)

여기선 추가할 데이터가 안 보인다.

디자인 화면에서 저장할 데이터와 그룹핑까지 다 했다.

초안 데이터베이스 설계를 끝냈다.

이제 6가지 규칙을 적용시키면서 데이터 중복이 발생하는지 아닌지를 보고, 발생한다면 테이블 분리를 하면 된다.

사용자 테이블에 임의의 데이터를 넣어 보자.

계정(username)은 겹칠 수 없으니 중복이 애초에 안 생긴다.(가짜 중복조차 아닌 듯)

패스워드는 가짜 중복이다. 겹쳐도 된다.

프로필 사진도 마찬가지다. 어떤 URL이 있어도 가짜 중복인 듯

사용자 테이블은 규칙을 어기는 게 없어서 그대로 둔다.

tasks의 제목을 보자. 투두 리스트를 해 보면 임무 이름이 겹친다고 해서 오류가 발생하진 않는다.

근데 진짜 중복일까 가짜 중복일까? 첫 번째 임무 제목을 수정하면 두 번째 임무 제목도 바뀌어야 할까? 아니다. 가짜 중복이다.

설명도 가짜 중복

마감 날짜도 가짜 중복

우선순위도 가짜 중복이다.

완료 여부는 FALSE, TRUE로 표현하는 거기 때문에 중복이라고 표현하진 않는다. FALSE를 FALSY라고 바꿀 일이 없다. 나중에 Boolean 형태로 데이터를 저장할 것이다. 일관된 데이터에 true, false로 표현할 수 있는 자료형으로 저장할 거다. 이걸 중복이라고 보진 않는다.

카테고리엔 University, Home, Work ... 이런 게 들어간다. 진짜 중복이다. 그래서 이걸 테이블 분리하려고 했더니 이미 카테고리 테이블이 있다. 그럼 지금 카테고리 컬럼은 카테고리 id(FK)로 바꾼다.

사용자 id(FK)를 보면 어떤 사용자가 어떤 임무를 등록했는지를 파악할 수 있는 형태의 데이터베이스 설계다.

tasks(임무): id, 제목, 설명, 마감 날짜, 우선순위, 완료 여부(true: 완료 / false: 완료 X), 카테고리 id(FK), 사용자 id(FK)

카테고리 테이블을 보자.

카테고리는 임무에서 설정할 수 있는 것이기 때문에 서로 연결이 되어야 한다. 관계 파악을 해 보자.

하나의 임무는 하나의 카테고리를 가진다.(기획자가 하나의 카테고리만 설정할 수 있다고 말했다고 치자.)

하나의 카테고리는 여러 개의 임무에 속한다.

임무 : 카테고리 = N : 1이다.

N인 임무 쪽에 FK가 붙는다. 이미 tasks에서 카테고리 id(FK)를 설정했다.

아이콘엔 어떻게 이름을 붙여야 할까? 프론트와 협의해야 한다. 프론트 입장에서 아이콘 이미지를 백엔드로부터 다운로드하겠다 아니면 이미지를 외부에서 다운로드하겠다라고 한다면 아이콘 이미지의 외부 URL을 써야 한다. 이미지 주소들이 있다.(그냥 URL로 가정한 듯)

색깔은 #325353 같은 색깔 코드를 입력해서 프론트한테 전달해도 되고, 아니면 색깔은 고유한 코드 값으로 우리끼리 통일해서 써도 된다. 빨간색을 RED라고 하고 초록색을 GREEN이라고 하자고 정하는 식으로 협의해서 설정하면 된다.

만약 튜플마다 RED, RED, RED로 나온다면 진짜 중복이다. 그래서 테이블 분리를 해야 한다.

colors(색깔): id, 색깔 코드

그리고 카테고리 테이블엔 색깔 id가 필요하다.

categories(카테고리): id, 이름, 아이콘, 색깔 id(FK)

이렇게 분리하는 게 정석적인 데이터 중복 없애는 방법이다. 만약 색깔 id를 안 하고 그냥 RED라고 일일이 쓴다면? 역정규화의 일부이긴 한데 입문 입장에선 어려울 수 있어서 일단 우린 정석적인 방법대로 하자.

focus_histories(집중 시간 히스토리)를 보자

focus_histories(집중 시간 히스토리): id, 집중한 시간(단위: 분), 기록 날짜

기록 날짜에 23.10.08. 이런 식으로 저장하면 되는데, 23.10.08. 23:05:01 이런 식으로 구체적으로 시간까지 적으면 더 좋다. 나중에 이걸 언제 기록했는지 파악하기 위해 정확한 날짜를 기록하면 좋다.

앱에서 날짜만 쓰는데 굳이 시간까지 기록해야 할까? 그 순간에 앱을 운영하는 데 있어선 날짜만 있어도 된다. 하지만 서비스를 운영함에 있어선 구체적인 데이터가 있으면 있을수록 활용도가 더 좋아진다. 날짜 + 시간 이런 식으로 데이터가 많으면 필요 없는 건 나중에 안 쓰면 된다. 그런데 날짜만 기록했다가 갑자기 나중에 서비스 기획이 바뀌어서 언제 기록했는지 시간까지 알아야 하면, 이전엔 데이터 기록을 안 했으니 복구할 방법이 없다. 그러니 안 쓰더라도 날짜 데이터 같은 건 시간 데이터까지 정확히 기록하는 게 좋다.

focus_histories를 보면 빠진 게 있다. 어떤 사용자가 집중했는지를 알 수 없다.

실제로 설계할 때도 이렇게 빠뜨릴 때도 있을 것이다. 이걸 언제 눈치채냐 하면, 설계를 하다가 프론트한테 각 사용자마다 집중한 시간 합계 내서 보내려고 하니, 어떤 사용자가 남긴 건지 없다는 걸 발견할 수도 있다. 이때 보완하기도 한다. 그렇게 해도 문제없다.

focus_histories(집중 시간 히스토리): id, 집중한 시간(단위: 분), 기록 날짜, 사용자 id(FK)

여기서 1번 id 사용자가 23년 10월 8일에 총 집중한 시간을 구할 수 있다.

테이블 초안)

• users(사용자): id, 계정, 패스워드, 프로필 사진

• tasks(임무): id, 제목, 설명, 마감 날짜, 우선순위, 완료 여부(true: 완료 / false: 완료 X), 카테고리, 사용자 id(FK)

• categories(카테고리): id, 이름, 아이콘, 색깔

• focus_histories(집중 시간 히스토리): id, 집중한 시간, 기록 날짜

최종 결과)

• users(사용자): id, 계정, 패스워드, 프로필 사진

• tasks(임무): id, 제목, 설명, 마감 날짜, 우선순위, 완료 여부(true: 완료 / false: 완료 X), 카테고리 id(FK), 사용자 id(FK)

• categories(카테고리): id, 이름, 아이콘, 색깔 id(FK)

• colors(색깔): id, 색깔 코드

• focus_histories(집중 시간 히스토리): id, 집중한 시간(단위: 분), 기록 날짜, 사용자 id(FK)

이렇게 하면 데이터베이스 설계는 끝났다. 이 설계 내용을 그대로 코드에 반영하면 된다.

지금까지 한 실습들을 내가 직접 해 봐야 한다. 이게 이 강의에서 가장 중요하다.

지금까지 DB 설계는 다 해 봤다.

엑셀에 완성된 형태의 테이블 구성과 컬럼들을 배치해 봤다.

이것들을 데이터베이스에 직접적으로 반영해 줘야 한다. 테이블과 컬럼을 만들어 줘야 한다.

세 가지 방법이 있다.

1. 데이터베이스에 SQL문을 직접 입력해서 반영하기

2. DB 관리 툴(MySQL Workbench, DBeaver 등) 활용하기. SQL을 사용하지 않더라도 클릭 몇 개 하면 테이블 만들 수 있다.

3. ORM 활용하기. 최근에 현업에서 많이 사용한다. Spring에선 JPA, 자바스크립트나 타입스크립트에선 TypeORM, Sequelize와 같은 데이터베이스를 직접적으로 편하게 다룰 수 있게 해 주는 라이브러리가 있다.

이 라이브러리를 활용하면 DB에서 테이블을 일일이 SQL을 활용해서 만들 필요 없이, 코드 내부에 테이블에 대한 내용들을 쭉 정의하게 되면, 라이브러리가 작성된 코드를 보고 DB에 직접 그 테이블을 생성해 주는 SQL 쿼리를 날려 준다. 즉 자연스럽게 DB에 테이블을 생성해 준다.

요즘엔 SQL을 직접 입력해서 테이블을 세팅할 일이 잘 없다.

학습 순서는 1 -> 2 -> 3을 추천한다.

휴대폰 번호나 주민등록번호처럼 숫자를 더해서 사용할 일이 없는 것들은 정수가 아니라 문자로 저장해야 한다.

10억 이하의 숫자를 INT를 써도 되는데, 10억을 넘어가면 BIGINT를 써야 한다.