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

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

 

마실가실 ERD (좌-리팩토링 전 / 우 - 리팩토링 후)

 

MSGS_REFACTORING_ERD

담당했던 테이블입니다.

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

 

 

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

 

 

 

🙋‍♀️

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

 

📑

참고 자료

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

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