DB 설계

ERD

Convention

• 예약어의 사용은 최대한 피한다

• table name은 소문자 단수형을 사용. 여러 단어로 된 이름을 사용한다면 _를 사용해 구분한다.

  • 최대한 적은 단어를 사용한다

• Primary Key의 name은 테이블명_id를 사용한다

• Foreign Key의 name은 부모테이블명_id를 사용한다

• column name은 소문자로, 띄어쓰기는 _로 대체한다

• 하나의 테이블이 너무 많은 column을 가지지 않도록 한다.

  • 보통 10개 이내가 적절하고, 15개 이상으로 넘어간다면 정보의 책임에 따라 테이블을 나눈다

• 시간을 의미하는 컬럼은 ~_at을 사용한다

  • 의미에 따라 과거형 (created_at), 현재형 동사(start_at)을 사용한다

• boolean 컬럼은 is_~ed를 사용한다 (is_deleted, is_automated)

  • success만 예외로 그대로 사용한다 (is_succeeded가 맞는데 success라는 단어를 자주 쓰니까)

• 기본적으로 soft-delete를 사용하며, 삭제 여부를 저장하는 is_deleted boolean 컬럼을 추가한다

• 기타 integer 컬럼의 컨벤션

  • 가격을 의미하는 컬럼은 price_~를 사용한다 (price_product, price_bid...)

생각할 사안

• auctions 테이블에서 제일 최신의 경매 현황을 가져올 때 (아마 첫번째 방법이 제일 좋을 듯함 DB의 INSERT/UPDATE가 최소이므로)
  1. auctions.auction_id를 사용해서 auctionLogs 테이블의 최신의 데이터를 가져오기
     • 제일 최신 데이터의 기준은 primary key의 순서로 (삽입 순서를 보장하니까)
     • SELECT * FROM ~ WHERE auction_id = ? ORDER BY PK DESC LIMIT 1; 으로 조회하며 되니까 PK를 조회에 사용 가능해서 쿼리문의 최적화는 제대로 가능함
     • JOIN한다면 효율을 위해서는 auctionLogs.auction_id를 INDEX KEY로 추가해야함
  2. auctions 테이블에 auctionLogs.PK값을 기록하는 컬럼을 추가하고, auctionLogs가 새로 삽입될 때마다 auctionLogs.PK값을 갱신?
     • logs에 삽입할 때마다 auctions 테이블도 UPDATE해야하니까 transaction내에서 하는게 많아짐
     • 조회 시에 JOIN 연산으로 한번에 조회하기 용이함
• 경매의 결과 데이터를 저장하는 테이블이 별도로 필요한지
  • logs 테이블 조회를 통해 결과를 역산하는 것이 가능은 함
  • 다만 여러 결과 데이터를 한번에 조회해야 할 경우에는 별도의 테이블을 생성하는 것이 유리할 것으로 생각됨
• foreign key 사용?
  • 외래키의 참조 무결성 제약으로 인해 데이터의 정합성을 유지하는데에는 도움이 됨
  • delete 옵션을 CASCADE로 설정했을 때 사고로 인해 부모 테이블의 데이터가 삭제되면 자식 테이블의 데이터도 삭제되어 주의가 필요함
  • 이외 개발 시, 테스트 데이터 삽입 시 순서를 맞춰야 한다던가, insert시 부모 테이블에 존재하는지 확인이 필요해서 자원을 조금 더 소모한다던가 등의 단점도 존재