[1년 후 마실가실] ERD 수정

1년 전 진행했던 마실가실 프로젝트를 🛠️리팩토링하며 정리한 내용입니다.

담당했던 테이블입니다.

사용자 테이블은 담당이 아니지만, 여행 일정 생성을 위해서는 필수 테이블이기에 같이 정리했습니다.

🏗️ ERD에서 다음 내역이 개선되었습니다.

공통

ID 타입을 VARCHAR → INT로 변경
- 인덱스 생성 및 조회 성능 향상
- AUTO_INCREMENT 활용을 통한 데이터베이스 입력 자동화 → 입력 실수 방지
등록일, 수정일 등 일자 관련 데이터 형식을 DATE → TIMESTAMP로 변경
- 시간 정보 추가
- CURRENT_TIMESTAMP 활용을 통한 데이터베이스 입력 자동화 → 입력 실수 방지
일부 데이터 크기 VARCHAR(255)로 조정
- VARCHAR: 데이터 byte + 데이터 길이 byte
  VARCHAR의 스키마가 255 이하일 때 1 Byte를 예약하고, 255를 초과할 때 2 Byte를 예약
  데이터 크기가 255를 초과할 필요가 없을 경우, 255로 조정
길이가 고정된 데이터의 경우 VARCHAR → CHAR로 변경
- CHAR는 길이가 고정되어 있어 데이터 저장 및 조회 시 일관된 성능을 보임
- 길이 정보를 저장하는 바이트로 인한 오버 헤드가 없음

여행 일자 테이블

+ 3차 리팩토링

(2024.08.04)

전에 알던 내가 아냐 Brand New Sound...

ERD 2차 리팩토링을 하다가 그런 생각이 들었습니다.

나 무슨 기준으로 테이블을 만들고 있는 걸까.. 🤔

기존 테이블 구조에 의하면 여행지가 중복된 데이터로 하염없이 쌓이기 시작하는데, 이래도 되는걸까..🤔

DB 설계가 잘못되었다..🫡

그래서 고쳤습니다.

기존 테이블은 페이지/동작을 기준으로 작성하였습니다.

* 예: 사용자 / 일정생성 / 일정후기 등

변경 테이블은 엔티티를 기준으로 작성하였습니다.
- 예: 사용자 / 일정 / 여행지 등
다중 필드를 제거하였습니다.
- 기존 테이블 구조의 경우, 목적지와 관련된 내용이 중복되어 기록됩니다.
- 중복 데이터가 반복될 수있는 부분을 제거하였습니다.
계산 필드를 제거하였습니다.
- 기존 여행 일정에 1일차, 2일차를 계산하는 필드를 제거하였습니다.
- 원본 데이터가 변경될 경우 계산된 필드가 올바르게 갱신되지 않으면 잘못된 정보를 제공할 수 있는 가능성을 제거하였습니다.
식별 관계를 줄였습니다.
- 식별 관계는 간단히 외래키가 자식 테이블의 PK 역할도 수행하는 관계를 의미합니다.
- 복합키 사용으로 인한 복잡성 증가나 성능 저하의 문제를 고려하여 식별 관계를 줄였습니다.

🙋‍♀️

본 포스트는 공부 목적으로 작성하였습니다.
보시는 도중 잘못된 부분이나 개선할 부분이 있다면 댓글로 알려주시면 수정하도록 하겠습니다.

📑

참고 자료

MySQL varchar(255)를 사용하는 이유?

이유 MySQL에서 테이블을 만들 때 varchar(255)를 자주 사용했다. varchar가 가변길이 타입으로 char에 비해 실제 저장한 데이터의 크기만큼 저장한다고 알고 있었다. 그런데 왜 하필 255인지는 생각해본

velog.io

DB 설계는 어떻게 해야 할까?

도대체 어떻게 설계해야 할까? 😂

velog.io