Notification 테이블 설계

[Huey-J]

@shinyubin989 유빈님! 논의가 필요해서 Discussions를 추가했습니다:)

피그마에서 알림 요구사항을 보면 공지사항과 기프티콘 만료 알림이 같이 있습니다.

그래서 테이블 구조를 아래와 같이 잡으면 어떨까 싶은데 어떠신가요?
알림 조회 시 SELECT * FROM notification LEFT OUTER JOIN announcement ON ... 식으로 조회하고자 합니다.

[shinyubin989]

@Huey-J 궁금한점 두가지가 있습니다!

1. 공지사항 알림인지, 만료알림인지 어떻게 구분할 수 있을까요?
2. 만료알림일 경우, 세개의 테이블을 조인하실 생각이실까요?? (알림, 기프티콘알림, 기프티콘 테이블)

[Huey-J]

@shinyubin989 우선 아래와 같은 쿼리문으로 진행할 예정입니다.

SELECT *
FROM notification
LEFT OUTER JOIN announcement
LEFT OUTER JOIN gifticon_expiration_alert
LEFT OUTER JOIN gifticon

답변

1. 현재 구조에서는 announcement_id 의 null 여부나 gifticon_expiration_alert_id 의 null 여부로 구분할 수 있습니다. 또는 notification에 type을 추가해도 좋을 것 같아요.
2. 넵 맞습니다! 추가적인 알림 타입이 생성될 수 있다고 생각해서 위와 같은 구조를 떠올렸습니다.

추가 논의

• 확인 여부의 경우 User 테이블에 '마지막 알림 확인 일시'를 추가하면 어떨까 싶어요!
  notification에 boolean으로 확인 여부를 추가하는 방식보다 저장되는 데이터 양도 적고, 업데이트 해야 하는 데이터 개수도 적다는 장점이 있습니다.
  해당 컬럼을 user에 추가되는게 조금..은 걸리긴 하지만 추가적으로 테이블을 생성하기에는 조금 애매... 하구요.. 추후에 이런 데이터가 많아진다면 그때 고민해 봐도 좋을 것 같습니다.
• 테이블 이름도 조금 고민이 됩니다. suffix나 prefix로 알림과 관련된 테이블이라고 표시하는 방식은 어떻게 생각하시나요?

[shinyubin989]

답변1 -> null여부로 판단하게되면 서비스 로직이 복잡해지지는 않을까..?하는 궁금증이 있는데요! 현희님이 생각하시는 대략적인 로직(?)이 궁금합니당

답변2 -> 좋습니다! 확장성있는 테이블구조인것같아요 👍🏼

추가논의1 -> 으음 트레이드오프 일거같네요! User에 넣게되면 로직이 굉장히 단순해질수있지만, User와 관련이 적은 필드를 넣어야한다는 점이 있고 / noti에 boolean으로 넣는다면 로직이 상대적으로 복잡해지지만 관련있는 필드를 넣을 수 있다는 점이 있겠네요. 개인적으로는 전자는 User테이블과 맥락이 맞지않는 필드를 추가하게 되는게 아닐까?하는 생각이 있어서, 로직이 조금 복잡해지더라도 이벤트 같은 기술을 사용해 로직을 분산시키면 어떨까 합니다!

추가논의2 -> 말씀해주신대로 알림테이블이라는 명시를 해줄수있는 방식이 더 좋을거같아요!

[Huey-J]

답변1 -> outer join으로 알림 목록 조회를 했을 때 아래와 같이 응답값을 내려줄 것 같은데요. 이후 프론트에서 각 ID의 null 여부에 따라 알림 타입을 판단할 수 있다고 생각했습니다. (저는 notification 테이블에 enum 타입을 추가하는 방식도 좋습니다)

[
  {
    "notificationId" : 1,
    "announcementId" : null,
    "gifticonExpirationAlertId" : 3,
    "gifticonId" : 5,
    // 생략...
  },
  {
    "notificationId" : 1,
    "announcementId" : 5,
    "gifticonExpirationAlertId" : null,
    "gifticonId" : null,
    // 생략...
  }
]

추가논의1 -> 이벤트로 로직을 분산시키는건 저도 좋은 것 같습니다! 하지만 어딘가에 알림을 어디까지 확인했는지 저장해야 하는데 해당 데이터를 어디에 저장하는게 좋을까요? 🤔

추가논의2 -> 넵 네이밍은 좀 더 생각해 보고 작업해 보겠습니다 ㅎㅎ

[shinyubin989]

1 -> 음음 아무래도 enum응 추가하게되면 정규화가 낮아지는 방식일 것 같아서, 말씀해주신 null로 보내는 방식이 좋을것같아요!

2-> 각 알림을 확인했는지/ 안했는지 여부를 각 알림이 알고있다면, 어디까지 확인했는지 알고있지 않아도 되지 않을까용??

@Huey-J

[Huey-J]

@shinyubin989 알림에 직접 체크 여부를 추가하는 건 생각보다 좀 복잡할 것 같습니다..!

우선 알림에는 기프티콘 만료 알림 처럼 특정 유저에게 할당되는 알림과, 공지사항 같이 모든 유저에게 할당되는 알림이 있습니다.
특정 유저에게 할당되는 알림은 엔티티에 '확인 여부'를 나타내는 컬럼을 추가하여 해결할 수 있지만, 모든 유저에게 공지되는 알림은 각 유저의 확인 여부를 개별적으로 처리해야 하기 때문에 엔티티에 컬럼을 추가하는 것으로는 부족합니다.

또한 알림이 여러 개 있을 때 한 번에 확인 여부를 업데이트해야 하는 리소스도 불필요할 수 있습니다.

제 생각에는 유저 테이블(또는 새로운 테이블)에 '최근 알림 확인 시간' 컬럼을 추가하여, 알림 목록을 조회할 때 해당 시간을 업데이트하고 (이벤트 활용?), 목록 조회 시 각 알림의 생성 일시와 '최근 알림 확인 시간'을 비교하여 반환해주면 어떨까 싶습니다.

대략적인 조회 쿼리는 다음과 같습니다.

SELECT *,
       IF(n.createdat <= DATE('2023-11-07'), true, false) # 알림 확인 여부
FROM notification n
         LEFT OUTER JOIN notification_announcement na
                         ON n.notification_id = na.notification_id
         LEFT OUTER JOIN notification_gifticon_expiration nge
                         on n.notification_id = nge.notification_id
         LEFT OUTER JOIN gifticon g
                         on nge.gifticon_id = g.gifticon_id
WHERE (g.user_id = 1 OR g.user_id IS NULL);

[shinyubin989]

@Huey-J 아하 공지사항은 하나로 처리되는군요
그러면 현희님 말씀대로 유저엔티티에 필드를 추가하거나 따로알림확인 테이블을 만드는게 좋아보이네요~!