키워드 정리

목표 D-day : 58 일

오늘은 프로젝트를 준비하면서 피드백 받은 내용을 정리해보겠습니다.

마지막 수정 ERD입니다.

• 프로그래밍 언어나 데이터베이스를 설계할 때는 일관성이 중요하다.

​ 예를 들어 Buyer.name의 길이는 varchar 100 인데 Seller.name은 varchar 50 인것처럼 일관성이 깨지지 않도록 합니다.

• 실제 Date가 명확히 사용되는 경우가 아니라면 DateTime을 사용하는 것이 이후 요구 사항이 변경된다고 하더라도 반영하기가 쉽다.

• 특히 길이에 대한 변경은 더 무거운 변경이 된다. immutable은 아니지만 변경이 어렵다.\

  소스코드 영역은 개발자가 제어할 수 있지만 데이터베이스는 그때 그때 변경할 수 없다.

  1. 칼럼을 중간에 삽입하거나 빼는 과정이 어렵고 어느 정도 크기의 장애가 발생할지 모릅니다.
  2. 데이터가 많은 경우 index를 추가하거나 삭제하는 경우도 마찬가지입니다.

• Buyer.defalut_xxx로 기본 배송지 주소를 테이블에 저장하는 방법도 최적화하는 좋은 방법이 입니다.
  자바 클래스를 설정하듯이 주소도 최적화를 위해서 필드를 추가하는게 아니라 주소 테이블에 기본 배송지 옵션을 넣는 것이 좋다고 생각합니다.
  예를 들어 defaultYN으로 하여 Y나 N만 넣어 관리하는 방법입니다.

  • 주소에 대한 필드가 변경시 기본 배송지 필드는 유연하게 대처하기 어렵습니다.
    예를 들어 해외 배송이 추가 된다면 한국 주소 구조와는 다르게 저장합니다. 기본 배송지로 최적화를 하게 된다면 해외 배송 요구사항에 맞게 Buyer테이블과 Address모두 수정하는 상황이 발생합니다.
  • Order 테이블도 배송 정보를 스냅샷처럼 가지고 있습니다. 그런데 주소에 대한 정보가 변경되면 테이블 구조가 변경되어야하므로 이런 경우 Json 필드를 사용하는게 좋을 수 있습니다.
    배송지 정보가 조인의 대상이 되는 경우가 드물기 때문에 한번 저장하고 조회만 되는 경우라면 Json 필드가 유리할 수 있습니다.
  • JSON 필드는 백업 데이터, 로그성 데이터, 그 당시의 데이터를 스냅스를 찍어놓고 조회하는 용도로만 사용된다면 나쁘지 않습니다.

• is_xxx는 boolean type

• xxxYN은 필드값이 Y,N인 경우

히스토리 테이블 관리 방법

1. 각 테이블 마다 히스토리 테이블이 있어야하는 경우
2. 필요한 테이블만 히스토리 테이블로 관리한다.
3. 변경된 내용만 히스토리 테이블로 관리한다.

히스토리를 관리하는 이유는 변경 이력을 확인하여 이전 데이터로 변경하거나 변경 이력을 통해 오류를 확인하기 위해서입니다.