June 24, 2025 엔티티 공통 규칙을 작성하고 엔티티 도출 과정에서 나눈 디스커션을 기록해둔 문서입니다.

1. 복합키를 사용하는 엔티티에서의 ID사용 여부 관련 디스커션

   
   package team03.mopl.domain.chat;
   
   import jakarta.persistence.Column;
   import jakarta.persistence.Entity;
   import jakarta.persistence.FetchType;
   import jakarta.persistence.GeneratedValue;
   import jakarta.persistence.GenerationType;
   import jakarta.persistence.Id;
   import jakarta.persistence.JoinColumn;
   import jakarta.persistence.ManyToOne;
   import jakarta.persistence.Table;
   import jakarta.persistence.UniqueConstraint;
   import java.time.Instant;
   import java.util.UUID;
   import org.springframework.data.annotation.CreatedDate;
   import team03.mopl.domain.user.User;
   
   @Entity
   @Table(name = "room_participants", uniqueConstraints = {
       @UniqueConstraint(columnNames = {"user_id", "room_id"})
   })
   public class RoomParticipant {
   
     @Id
     @GeneratedValue(strategy = GenerationType.AUTO)
     private UUID id;
     //JPA 사용시 없으면 불편함...?
   
     @ManyToOne(fetch = FetchType.LAZY, optional = false)
     @JoinColumn(name = "user_id", nullable = false)
     private User user;
   
     @ManyToOne(fetch = FetchType.LAZY, optional = false)
     @JoinColumn(name = "room_id", nullable = false)
     private Room room;
   
     @CreatedDate
     @Column(name = "created_at", nullable = false, updatable = false)
     private Instant createdAt;
   
   }
   
   

   1. id, user_id, room_id, @UniqueConstraint를 함께 쓰기

      장점 : 따로 ID가 있는 거 자체가 DB 롤백에 안 맞다.

      단점 : erd와 안맞음

   2. user_id, room_id, @UniqueConstraint

      기억이 안나. . .

   <aside> 🎉

   FIX : id, user_id, room_id, @UniqueConstraint를 함께 쓰기

   </aside>

1. LocalDateTime vs Instant

   <aside>

   Instant : UTC 기준

   • 1970 . . .
   • Nano second 까지
   • 병운님 : UTC ~ 한국 시간 → 9시간 계산 → 우리 나라에서 쓰려면 변환해야 한다. → 오류
   • 가입일, 작성일정도에서는 too much, 로그 기록용 시간(utc 기준이 필요할때 적절), 분산 시스템 간 절대 시간 비교에 적절(kafka,redis) </aside>

   <aside>

   LocalDateTime

   • 날짜, 시, 분, 초\

   • 사람이 이해하기 좋음 </aside>

   • 창우님 : 개인적으로 Instant 불호ㅎㅎ LocalDateTime은 근본. 근본에는 이유가 있슴

   • 이유 : 포멧팅하기 편하다. 한국 시간으로의 변환에 문제가 있을 수 있다.

   <aside> 🎉

   FIX : 엔티티 (LocalDateTime) - DB(TIMESTAMP)

   </aside>

1. GenerationType.AUTO VS GenerationType.IDENTITY

   https://newwisdom.tistory.com/90

   → 이후 알림에서 MongoDB를 쓸 수 있으니, 벤더에 종속되지 않는 AUTO 를 선택하자

   <aside> 🎉

   FIX : GenerationType.AUTO

   </aside>

1. Dm의 senderId → 객체를 들고오느냐, ID를 들고오느냐

     @ManyToOne(fetch = FetchType.LAZY)
     @JoinColumn(name = "dm_room_id", nullable = false)
     private DmRoom dmRoom;
   

   • 단점 : m.getSenderId().getEmail -> n+1(fetch join, batchsize 사용해야함)

    @Column(name = "dm_room_id", nullable = false)
    private UUID dmRoomId;
   

   • 장점 : UUID 쓰면 레포지토리에서 조회 해야함 걍 쓰면 댐 성능 씹상타치(조회 하기 좋음)

   // dm.getSenderId().getEmail()
   // dm.getSenderId().getEmail()
   // 창우님 : 되던데, 찾아보겠습니다 -> OK!! 되면 좋겠습니다
   

   <aside> 🎉

   FIX : 본인이 편한 거 써보죠?! OK

   </aside>

   ---