ERD 설계

팀원들이 프론트 작업을 하고 있는 동안 나는 기존의 api명세서를 바탕으로 DB구축에 들어갔다.
우선 웹서비스를 이용하는 유저의 정보를 담는 user 테이블과, 해당 유저가 리뷰나 좋아요를 남길 수 있는 대상인 movie_info 테이블이 주요 테이블이라 판단하여 ERD 정중앙에 위치시켰다.

comment 테이블은 user와 movie_info의 기본키를 외래키로 받고 description컬럼에 유저가 작성한 코멘트 문장이 들어갈 수 있게 하였다. 또한 코멘트가 언제 작성되었는지 실시간으로 알려주기 위해 timestamp 컬럼을 추가하였다.

movie_like와 comment_like 테이블은 각각 유저가 영화에 남긴 좋아요, 다른 유저가 작성한 코멘트에 남긴 좋아요를 의미한다. 유저가 좋아요를 누르면 해당 테이블의 행이(row) 증가하기 때문에 좋아요의 수는 전체 행(row)의 개수를 반환하도록 하였다.

fav_moive은 인생영화를 등록하는 테이블이며 유저와 영화 테이블의 기본키를 외래키로 받아온다.
(개인적으로 테이블명을 life_movie로 바꾸고 싶다 판단하여 팀 회의 때 제안해 볼 생각이다.)

테이블 생성

show databases;
use moviecaster;
​
CREATE TABLE user (
    useridx INT AUTO_INCREMENT PRIMARY KEY,
    userid VARCHAR(30) NOT NULL,
    pw VARCHAR(255) NOT NULL,
    email VARCHAR(100) NOT NULL,
    nickname VARCHAR(50) NOT NULL,
    img VARCHAR(255), -- 프로필이미지(경로(path)를 저장)
);
CREATE TABLE movie_info (
	movieidx INT AUTO_INCREMENT PRIMARY KEY,
    title VARCHAR(100) NOT NULL,
    description VARCHAR(4000) NOT NULL, -- 영화 줄거리 ('desc'는 SQL 예약어 이므로 오류발생 -> 'description'으로 변경)
    director VARCHAR(100) NOT NULL,
    date VARCHAR(100) NOT NULL, -- 데이터 타입 date로 바꿀지 고민, api에서 받아오는 형식이 무엇인가에 따라 결정
    age INT NOT NULL,
    pic1 VARCHAR(255), -- 트레일러 이미지1, 경로만 저장
    pic2 VARCHAR(255), -- 트레일러 이미지2, 경로만 저장
    pic3 VARCHAR(255), -- 트레일러 이미지3, 경로만 저장
    genre VARCHAR(100) NOT NULL
);
CREATE TABLE movie_like ( -- 다수의 유저가 영화 하나에 좋아요 누른다(n:1 관계), (좋아요 개수 = row의 개수)
    movielikeidx INT AUTO_INCREMENT PRIMARY KEY,
    useridx INT NOT NULL,
    movieidx INT NOT NULL,
    FOREIGN KEY (useridx) REFERENCES user(useridx), -- 어떤 사용자가 좋아요를 눌렀는지 식별.
    FOREIGN KEY (movieidx) REFERENCES movie_info(movieidx) -- 어떤 영화에 대한 좋아요인지 식별.
);
CREATE TABLE fav_movie ( -- 유저가 등록한 인생작품, 유저 1명이 여러개의 영화를 등록할 수 있으므로 1:n 관계
    favmovieidx INT AUTO_INCREMENT PRIMARY KEY,
    useridx INT NOT NULL,
    movieidx INT NOT NULL,
    FOREIGN KEY (useridx) REFERENCES user(useridx), -- 어떤 사용자가 좋아요를 눌렀는지 식별.
    FOREIGN KEY (movieidx) REFERENCES movie_info(movieidx) -- 어떤 영화에 대한 좋아요인지 식별.
);
CREATE TABLE comment ( -- 유저가 영화에 남기는 한줄평
	commentid INT AUTO_INCREMENT PRIMARY KEY, -- 기본키를 기존의 'reviewid'에서 테이블 이름과 의미가 통하도록 수정(윤혜님 피드백)
    rate INT CHECK(rate >= 1 AND rate <= 5) NOT NULL, -- 평점을 1과 5 사이의 값만 허용하여 받음
    useridx INT NOT NULL,
    movieidx INT NOT NULL,
    description  VARCHAR(100), -- 한줄평 글자수-> 글자수는 임시로 두고, html 작성하면서 width가 정해지면 적당하게 조절할 예정
    timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP, -- 리뷰가 작성된 시간
    FOREIGN KEY (useridx) REFERENCES user(useridx),
    FOREIGN KEY (movieidx) REFERENCES movie_info(movieidx)
);
​
CREATE TABLE comment_like ( -- 내가 쓴 리뷰에 타인이 좋아요를 누른 횟수, 좋아요 개수 = row의 개수 )
	commentlikeidx INT AUTO_INCREMENT PRIMARY KEY,
    commentid INT NOT NULL ,
    useridx INT NOT NULL , 
    FOREIGN KEY (commentid) REFERENCES comment(commentid),
    FOREIGN KEY (useridx) REFERENCES user(useridx)
);

erd를 기반으로 실제 mysql 쿼리문을 작성 해 보았다.
프로젝트를 진행하면서 필연적으로 테이블 구조를 수정해야 할 일이 생길 것 같다.

문득 코멘트나 좋아요를 누른 유저가 회원탈퇴를 하면 기존의 데이터를 어떻게 처리해야 할 지에 대해 의문이 들었다.

+)현재 떠오른 아이디어는 user 테이블에 deleted_user(varchar[1]) 컬럼을 추가하고 default 속성을 통해 y/n 중 n를 기본값으로 하여 회원탈퇴 시 해당 컬럼의 값을 y로 설정하면 기존 회원과 탈퇴한 회원을 구분할 수 있다는 생각을 하였다.