Issue: ⚙️ Refactoring

Description

-- auto-generated definition
create table review
(
    id            bigint auto_increment
        primary key,
    member_id     bigint        not null,
    board_id      bigint        null,
    badge_taste   varchar(20)   null, -- 맛 뱃지
    badge_brix    varchar(20)   null,  -- 당도 뱃지
    badge_texture varchar(20)   null, -- 질감 뱃지
    rate          decimal(2, 1) null,
    content       varchar(255)  null,
    created_at    datetime(6)   null,
    modified_at   datetime(6)   null,
    is_deleted    tinyint(1)    null,
    is_best       tinyint       null
);

create index idx_board_id
    on review (board_id);

뱃지에 NULL이 포함되면서 효율적으로 뱃지 개수를 가져올 수 없음
만약, 리뷰가 1000개 이상이라면 매번 전체 리뷰를 불러와야 함
- 버퍼 풀 부담 및 서버 부담

이를 개선하기 위해 테이블 분리를 요청


create table review_after
(
id                    bigint auto_increment primary key,
member_id     bigint        not null,
board_id         bigint        not null,
rate                decimal(2, 1) not null,
content          varchar(255)  not null,
created_at     datetime(6)   default now(),
modified_at   datetime(6)   default now(),
is_deleted      tinyint(1)    default false,
is_best           tinyint       default false
);

create index idx_board_id on review_after(board_id);

create table review_badge ( review_id bigint not null, category varchar(20) not null, badge_type varchar(20) not null, primary key (review_id, category), foreign key (review_id) references review_after(id) );


- 장점
    - 'NULL' 제거를 통한 물리 저장 공간 절약
    - 확장성이 좋아짐
        - 뱃지는 기획 요구 사항이 변경될 가능성이 높다고 판단
- 단점
    - Join이 사용되므로 성능의 영향이 존재할 수 있음
        - 테스트로 확인 필요
    - 삽입 1회에서 -> 3회로 증가

- 둘 다 장단점은 있지만 리뷰 특성 상 계속 데이터가 쌓이므로 대량의 데이터에서도 잘 처리할 수 있는 방법이 필요
- 이를 위해 테이블 분리가 필요하다 판단함

## To do
- [ ] 성능 테스트
- [ ] 테이블 변경
- [ ] 로직 변경

## ETC
- 테스트를 진행한 후 평가해보겠습니다

eco-dessert-platform / backend

⚙️ 리뷰 테이블 변경 요청 #307

Issue: ⚙️ Refactoring

Description