커뮤니티 기능을 위한 DB 테이블 설계(Access level, Like)

[hgo641]

안건1 : 접근 권한(Access level) 설계

커뮤니티 기능이 생기면서 여행 게시물 접근 권한이 세분화되었습니다.

• 전체 공개 & 링크 공유

접근 권한을 DB에서 어떻게 설계하면 좋을지 의견을 남겨주세요!

안건2 : 좋아요(Like) 설계

전체 공개된 게시물에 좋아요를 남길 수 있는 기능이 추가됐습니다.
좋아요를 DB에서 어떻게 설계하면 좋을지 의견을 남겨주세요!

[LJW25]

안건1 : 접근 권한(Access level) 설계

• 링크공유는 현상 유지
• 전체공개의 경우 shared_trip과 동일한 형태로 , code 없이 status만 사용(이 status는 usable/delete와 별개로 공개 여부를 나타내는 status)
• 테이블 이름은 published_trip 어때요? 커뮤니티에 공개하는 행위가 publish의 의미와 어울린다고 생각함.
• 아래 사진을 참고하면 되지만, 내맘대로 표를 만들어 본다면?

[ published_trip ]

key	column	type
PK	id	BIGINT
FK	trip_id	BIGINT
	published_status	BOOLEAN
	created_date	..
	updated_date	..
	status	..

---

안건2 : 좋아요(Like) 설계

• 심플하게 가자! 는 의미에서 trip_id, member_id 만 가져도 된다고 생각.
• soft delete 하면 장점보다 오히려 복잡해질것같아서 얘만 hard delete로 가면 어떤가 합니다.
• 얘도 내맘대로 테이블을 만들어본다면?

[ like ]

key	column	type
PK	id	BIGINT
FK	trip_id	BIGINT
FK	member_id	BIGINT
	created_date	..
	updated_date	..
	status	..

[jjongwa]

뭐야뭐야

[jjongwa]

안건1 : 접근 권한(Access level) 설계

저는 기존 trip 테이블에 published_status 컬럼을 추가하는 방식이 가장 간단하다고 생각해서 한 표..!

안건2 : 좋아요(Like) 설계

이 부분은 위에 이오가 설계한 테이블처럼 따로 분리해 놓는게 좋다고 생각합니다.
사실상 이 방식밖에 없을지도?
hard delete는 내일 다같이 논의해봐요.

[waterricecake]

안건 1

• 저도 published_trip table을 하나 추가하는 것보다 trip테이블에 컬럼추가하는 것이 더 깔끔하다고 생각합니다

안건 2

• 이오의 방식대로 좋아요 테이블을 만들어서 trip-user 이렇게 매칭시키는 게 좋습니다
• hard delete의 경우 전체 공개를 해제하더라도 좋아요가 사라지지 않는다면 동의 괜찮은것 같지만 사라질 경우 soft delete를 해야한다고 생각합니다.

[hgo641]

안건1 : 접근 권한(Access level) 설계

저는 전체 커뮤니티용 테이블 따로 분리하는 거 생각했어요! publish_trip 좋아요!
이유는 분리되어 있는 편이 확장성 좋다고 생각해서ㅎㅎ... 못하게 될 수도 있겠지만... ㅎㅎ 지금 미리 분리해도 크게 리소스 드는 건 없다...! 고 생각했어요.

결론 : publish_trip은 추가적인 정보(조회수, 게시날짜)가 생길 여지가 많아서 분리하고 싶다! publish_trip은 실제 trip과 다른 생명주기를 가지고, trip이 항상 publish_trip의 정보와 함께 조회되는 것이 아니기에 테이블을 분리하고 싶다!

안건2 : 좋아요(Like) 설계

저도 좋아요 테이블 분리! trip_id, user_id를 가지고 있는 형태 생각했어요!
나중에 캐싱 저장소를 사용할 확률이 높기 때문에! 분리하자!

[mcodnjs]

안건1 : 접근 권한(Access level) 설계

아래와 같이 trip에 is_published 라는 status 필드 추가!
새로운 테이블을 만드는 것이 아닌, 필드만 추가하는 이유는!
어떤 trip이든 언제나 publish 될 수 있는 상태라 생각하였고, publish된 trip과 되지 않은 trip의 차이점은 publish 상태 뿐이라 생각하였습니다!

안건2 : 좋아요(Like) 설계

좋아요 테이블 분리!
그리고 좋아요 개수는 trip 필드에 없어도 되려나 .. ? 조회수는 .. 있을 법 한데 ..

[LJW25]

결론

안건 1

• created_at을 비즈니스 로직에서 사용하는 것이 잘못됬다 -> 정렬을 id 순으로 변경한다.
• trip, published_trip 모두 id 순으로 정렬한다. created_at은 단순 기록의 용도로 사용.
• published_trip은 published_date를 별도로 저장하지 않고, id, trip_id, base_entity만을 가진다.

안건 2

• like는 id, member_id, trip_id, like_date 만을 가진다.
• base_entity는 가지지 않는다.
• 좋아요 취소, 여행/멤버 삭제 시 hard delete 한다.