알림 시스템 이해

나는 SE와 다른 곳에서 통지 시스템을 구축하는 방법으로 찾고있다 자신은 여기 허용 대답을 수있는 솔루션을 그려 발견 : /programming/9735578/building-a-notification-system 하는 용도 이 구조 :

╔═════════════╗      ╔═══════════════════╗      ╔════════════════════╗
║notification ║      ║notification_object║      ║notification_change ║
╟─────────────╢      ╟───────────────────╢      ╟────────────────────╢
║ID           ║—1:n—→║ID                 ║—1:n—→║ID                  ║
║userID       ║      ║notificationID     ║      ║notificationObjectID║
╚═════════════╝      ║object             ║      ║verb                ║
                     ╚═══════════════════╝      ║actor               ║
                                                ╚════════════════════╝

누군가 (행위자)가 변경하고 (동사 = 추가, 요청한 ..) 무언가 (객체 = 이벤트, 우정 ..)에 대한 알림은 사용자 (제목)에게보고됩니다. 다음은 표준화 된 데이터 구조입니다 (MongoDB를 사용했지만). 특정 사용자에게 변경 사항을 알려야합니다. 따라서 사용자 별 알림입니다. 100 명의 사용자가 참여한 경우 100 개의 알림을 생성합니다.

처음에는이 방법을 이해했다고 생각했지만 구현할 준비가되었을 때 특히 잘 이해하지 못했음을 깨달았습니다. 답변에 대한 마지막 몇 가지 의견은 솔루션을 이해하는 데 어려움이있는 다른 사용자의 질문입니다.

이것이 내가 따르는 모델인지 확실하지 않지만, 그것이 가지고있는 투표의 수를 감안할 때, 그것을 이해 하면 도움이 될 것이라고 확신 하며, 더 자세히 배우고 싶습니다. 이 솔루션을 이해하는 데 어려움을 겪은 다른 사람들에게도 유용하게 사용되기를 바랍니다 (실수 로이 질문을 지시하는 답변에 대한 의견을 남길 인터넷 포인트가 충분하지 않습니다. 누구든지하십시오!)

질문

올바르게 이해하면 notificationObjectID 는 notification_object 테이블을 가리키는 외래 키 이고 notificationID 는 알림 테이블을 가리키는 외래 키 입니다. 것 같다 객체 알림 (예 : 특정 이벤트 또는 포스트)에 관한 데이터베이스 항목의 ID를 참조 외래 키해야하지만, 우리는 다음 다른 필드 ID가 속해있는 테이블을 표시하기 위해 필요하지 않습니다?

저자는 썼다

notification_object.object는 문자열 "friendship"과 같은 변경 유형을 식별합니다. 내가 말한 추가 데이터가있는 변경된 오브젝트에 대한 실제 참조는 notification_change.notificationObjectID에 있습니다.

그것은 나에게 이해가되지 않는 것 같습니다. 객체는 문자열 (enum?)이고 notificationObjectID는 알림이 관련된 객체를 나타내는 외래 키입니까? 그렇다면 가운데 테이블과 오른쪽 테이블은 어떻게 연결되어 있습니까?

가운데 테이블은 알림이 어떤 객체 (또는 객체 유형) (예 : 이벤트 또는 게시물)인지 지정합니다. 그런 다음 notification_change 에 동일한 객체 유형을 가리키는 많은 항목을 가질 수 있으므로 알림 을 번들로 묶을 수 있습니다 (예 : "X의 벽에 게시 된 25 명의 사용자). 따라서 중간 테이블과 오른쪽 테이블 간의 1 : n 관계입니다.

그러나 왜 왼쪽 테이블과 중간 테이블 사이에 1 : n 관계가 있습니까? "샘의 벽에 게시 된 25 명의 사용자"와 "메리가"금요일 피크닉 "이벤트에 동일한 알림 ID를 제공합니까? 동일한 사용자에 대한 모든 알림에 동일한 알림 ID가있는 이유는 무엇입니까? 왼쪽?

성능 질문-John이 Mary의 피크닉 이벤트에 대한 의견을 게시한다고 말합니다. notification_change 항목을 만들기 전에 Mary 's Picnic에 대한 notification_object가 이미 있는지 확인하기 위해 조회를 수행해야 할 것 같습니다 . 이것이 성능에 부정적인 영향을 미치거나 문제가 아닌가? 우리가 알고 얼마나, 이전 단락에서 질문을 계속 통지 지점 항목 notification_object을 에?

이러한 철저한 질문에 감사하고 혼란을 겪은 것에 대해 죄송합니다. 최초 답변 후 1 년이 지나고 지금은 3 년이 지난 후에 의견을 말하십시오. 백엔드에 알림을 저장하는 데 실제로 적용하지 않고 좋은 판단을 내리는 지 확실하지 않습니다.

나는 글을 쓰는 시점에 생각한다.

• 예, 아니오, notificationID는 외래 키이고 notificationObjectID는 아니 었습니다. 테이블을 묶으려면 다른 FK 필드가 필요합니다. 나는 그것에 대해 명확하지 않은 내 몽고 경험을 비난합니다 :(
• 예, 아니오, notification_object.object는 문자열 또는 복잡한 것 (JSON 또는 FK)으로 가질 수 있으므로 모호합니다. 제 경우에는 명사였습니다.

따라서 모두 알림 모양에 따라 다릅니다. 간단한 경우, 전체 알림을 친구 페이지와 같은 일부 URL에 연결하려고합니다. 즉, 객체 (entityType)를 문자열로 사용하는 것이 유용한 이유는 URL을 연결하는 것입니다.

" 친구 요청 3 개가 추가되었습니다" 알림을 다르게 저장할 수 있습니다.

한 번에 하나씩 표시하려면 특정 친구 사용자에게 연결되는 알림 3 개, 알림 객체 3 개 (friend_request) 및 notification_change에 3 개의 항목이 있습니다.

하나의 알림을 표시하려면 1 개의 알림, 1 / 개 이상의 객체 및 3 / 개 이상의 작업이 있습니다. 따라서이 복잡한 경우«사용자 A, 사용자 B, 사용자 C로부터 3 명의 친구 요청이 있습니다»와 같이 각 사용자에 대해 notificationObjectID를 사용하고 알림 텍스트에 여러 개의 링크가 있습니다.

1 개 또는 3 개의 friend_request 객체를 사용해야합니까? 그것은에 달려있다

1. 목적은 무엇이며 행동은 무엇입니까? «아티클이 좋아요 / 댓글»입니까? 또는«좋아요 / 설명 추가»이며 개체 계층 구조가 표시 중에 만 연결됩니까? 다음은 의미 적으로 매우 가까운 것처럼 보이는«사용자 언급»과«사진 설명»을 구별하는 페이스 북입니다. 동일한 사진, 동일한 배우이지만 서로 병합 될 수있는 다른 알림이 있습니다.

2. 알림을 제거하거나 기록이 필요합니까? 따라서 친구 요청을 보낸 다음 취소하거나 댓글을 달고 기사를 삭제 한 다음 다른 항목과 달리-이력을 (다른 작업으로) 최종 사용자에게 두 가지 다른 작업으로 표시해야합니까? 아마 아닙니다. 또한 기술적으로 더 복잡합니다. 기존의 notification_object가있는 경우 검색해야하며 새 notification_change를 추가하십시오 (그렇지 않은 경우 새 객체 추가) 나중에 notification_change를 통해 검색하여 제거해야합니다. 대신 동일한 알림에 다른 notification_object를 추가하고 작업이 계단식으로 삭제 된 경우 제거합니다.

반면에, 기록에서 아무것도 지워지지 않는 동작 그룹을 갖는 것이 유용한 경우가있을 수 있습니다.

글을 쓰는 시점에서 왼쪽 테이블과 중간 테이블 사이의 1 : n 관계가 수행 된 이유는 동일한 엔터티 (중간 테이블)의 행위자뿐만 아니라 여러 개체 / 엔터티별로 알림을 그룹화 할 수 있다는 것입니다.

그러나 하나의 이벤트에 대해 사용자 별 알림이 생성되도록 왼쪽 중간 관계를 n : 1로 되돌려 전체 사례를 단순화하고 스토리지를 최적화 할 수 있습니다.

이렇게 보이게하겠습니다 ..

╔═════════════╗      ╔═══════════════════╗      ╔════════════════════╗
║notification ║      ║notification_object║      ║notification_change ║
╟─────────────╢      ╟───────────────────╢      ╟────────────────────╢
║ID           ║←—n:1—║ID                 ║—1:n—→║ID                  ║
║noteObjFK    ║      ║entityType         ║      ║noteObjFK           ║
║viewerUserID ║      ║entityID           ║      ║actionOnEntity      ║
╚═════════════╝      ╚═══════════════════╝      ║actorUserID         ║
                                                ╚════════════════════╝

이것이 도움이 되었기를 바랍니다.