[BSVR-123] DB 컨벤션에 맞춰 BaseEntity 생성

[EunjiShin]

📌 개요 (필수)

• 변경된 DB 컨벤션에 맞춰 BaseEntity를 생성하고, 엔티티 클래스에 적용했어요.

🔨 작업 사항 (필수)

• entity들에 BaseEntity 적용 및 충돌 코드 수정

🌱 연관 내용 (선택)

• 각자 작업 진행 중일 것 같아서 entity만 수정하고 도메인은 그대로 뒀어용
• 도메인 클래스는 담당자가 작업하면서 필요에 따라 변경해주시면 됩니다~!
  • 이제 DB 테이블에는 id, created_at, updated_at, deleted_at 전부 저장되니 각 도메인에선 당장 필요한 필드만 추가하면 될 것 같아용
  • 지금 당장은 도메인에 추가 안해도, 나중에 필요할때 추가하면 디비에서 꺼내올 수 있으니 문제 없음! ✨
• created_at, updated_at은 @PrePersist, @PreUpdate를 통해 동작해요. 즉, 어플리케이션을 통해서가 아니라 DB에 sql을 직접 날리는 경우엔 동작하지 않아요 (data.sql로 데이터 삽입하는 경우 등)
  • 지금은 ddl-auto를 이용해 스키마를 생성하지만, 실제 개발 / 운영 환경에선 직접 ddl 스크립트를 작성해야해요.
  • 그때 테이블 각 필드 created_at, updated_at에 디폴트 값을 배정해주어야 합니덩

[github-actions]

Test Results

7 tests  ±0   7 ✅ ±0   0s ⏱️ ±0s
3 suites ±0   0 💤 ±0 
3 files   ±0   0 ❌ ±0 

Results for commit d8b8d2f. ± Comparison against base commit ad8dd29.

[pminsung12]

Ack!

[pminsung12]

누나 어떤건 builder로 하고 어떤 건 allargscontructor로 했던데, 혹시 도메인마다 다르게 적용한 이유가 있어?

[EunjiShin]

아 큰 이유는 없어! 빌더랑 allargsconstructor은 사실상 동시에 쓰여도 상관은 없당
내 티켓에서 빌더 쓴 이유는 동일한 자료형의 필드가 여러개 있어서, 생성자를 쓰면 순서 실수가 있을 것 같아서였어~
빌더나 생성자를 아예 팀 컨벤션으로 강제하기보단, 필요에 맞게 사용하면 될 듯 해!