Facebook 좋아요 알림 추적(DB Design)

Facebook 좋아요 알림 추적(DB Design)

저는 페이스북의 데이터베이스가 알림을 추적하기 위해 어떻게 구성되어 있는지 알고 싶습니다.

Facebook처럼 복잡하지는 않을 것입니다.알림을 위한 간단한 테이블 구조를 상상해 보면 다음과 같습니다.

notifications (id, userid, update, time);

다음을 사용하여 친구의 알림을 받을 수 있습니다.

SELECT `userid`, `update`, `time`
FROM `notifications`
WHERE `userid` IN 
(... query for getting friends...)

그러나 어떤 알림이 읽혔는지, 어떤 알림이 읽지 않았는지 확인하기 위한 테이블 구조는 무엇이어야 합니까?

이것이 최선의 방법인지는 모르겠지만, 저는 다른 사람으로부터 아이디어를 얻지 못했기 때문에, 이것이 제가 할 일입니다.저는 이 답변이 다른 사람들에게도 도움이 되기를 바랍니다.

테이블이 2개 있습니다.

notification
-----------------
id (pk)
userid
notification_type (for complexity like notifications for pictures, videos, apps etc.)
notification
time


notificationsRead
--------------------
id (pk) (i dont think this field is required, anyways)
lasttime_read
userid

알림 테이블에서 알림을 선택하고 알림 읽기 테이블에 가입하여 마지막 읽기 알림과 ID > 알림 ID 행을 확인하는 것입니다.그리고 알림 페이지가 열릴 때마다 알림 읽기 테이블의 행을 업데이트합니다.

읽지 않은 알림에 대한 쿼리는 다음과 같습니다.

SELECT `userid`, `notification`, `time` from `notifications` `notificationsRead`
WHERE 
`notifications`.`userid` IN ( ... query to get a list of friends ...) 
AND 
(`notifications`.`time` > (
    SELECT `notificationsRead`.`lasttime_read` FROM `notificationsRead` 
    WHERE `notificationsRead`.`userid` = ...$userid...
))

위 쿼리가 선택되지 않았습니다.@espais의 DB 디자인 아이디어 덕분입니다.

다른 테이블을 추가할 수 있습니다...

tblUserNotificationStatus
-------------------------
- id (pk)
- notification_id
- user_id
- read_status (boolean)

기록을 유지하려면 X개의 최신 알림을 유지하고 목록에서 마지막 알림보다 오래된 나머지 알림을 삭제할 수 있습니다.

알림을 제공할 때 해당 시간에 사용할 수 있는 모든 관련 알림을 제공하는 경우 알림 이벤트에 타임스탬프를 첨부하고 각 사용자가 알림을 마지막으로 받은 시간을 추적하여 이 작업을 간소화할 수 있습니다.그러나 다중 서버 환경에서는 동기화에 주의해야 합니다.이 접근 방식에는 실제 날짜/시간 스탬프가 필요하지 않고 단조롭게 증가하는 것이 있습니다.

여기서는 아무도 통지가 보통 다시 발생한다는 사실을 언급하지 않습니다. 즉, 다음 거래에 대한 통지는 항상 동일하지만 거래 ID 또는 날짜가 다릅니다. { 새로운 다가오는 지불이 있습니다: @payment.만료 날짜가 @dueDate}인 ID입니다.다른 표에 텍스트가 있는 것도 도움이 될 수 있습니다.

1. 나중에 알림 텍스트를 변경하려는 경우
2. 알림 테이블을 언어 코드로 계층화하고 적절한 문자열을 검색할 수 있기 때문에 앱을 다국어로 만드는 것이 더 쉽습니다.

따라서 사용자 아래에 중간 테이블과 연결된 추상적인 알림에 대한 테이블도 만들었습니다. 이 테이블에서는 한 가지 알림 유형을 한 명의 사용자에게 여러 번 전송할 수 있습니다.또한 알림을 외부 키 ID가 아닌 사용자에게 연결했지만, 더 빠른 읽기 속도를 위해 모든 알림에 대한 알림 코드를 만들고 해당 코드의 막대 필드를 full_text 색인화했습니다.이러한 알림은 특정 시간에 전송되어야 하기 때문에 개발자가 작성하는 것이 더 쉽습니다.

NotificationService::sendNew( Notification::NOTE_NEW_PAYMENT, ['paymentId'] => 123, ['dueDate'] => Carbon::now(), 'userIdToSendTo' );

이제 제 메시지에는 문자열에 삽입된 사용자 정의 데이터가 포함될 것이기 때문에, 앞서 두 번째 인수에서 알 수 있듯이, 데이터베이스 블로그에 저장하겠습니다.이와 같이

$values = base64_encode(serialize($valuesInTextArray));

이는 알림을 다른 테이블에서 분리하고 싶기 때문에 알림 테이블과 알림 테이블 간에 불필요한 FK 관계를 생성하고 싶지 않기 때문입니다. 예를 들어 알림 234가 트랜잭션 23에 첨부되어 있다고 말하고 해당 트랜잭션 ID에 가입하여 가져올 수 있습니다.이를 분리하면 이러한 관계를 관리하는 데 드는 오버헤드가 줄어듭니다.단점은 알림을 삭제하는 것이 거의 불가능하다는 것입니다. 예를 들어 트랜잭션이 삭제되지만 제가 결정한 사용 사례에서는 어차피 이것이 필요하지 않습니다.

다음과 같이 App 쪽의 텍스트를 검색하여 작성하겠습니다.ps. 나는 누군가 vksprintf 함수를 사용하고 있습니다(https://github.com/washingtonpost/datawrapper/blob/master/lib/utils/vksprintf.php), 는 그에게 소품!

$valuesToFillInString = unserialize(base64_decode($notification->values));
vksprintf( $notificationText->text, $valuesToFillInString )

색인화할 필드도 확인합니다. 이 필드를 기준으로 찾거나 정렬하기 때문입니다.

내 데이터베이스 설계는 다음과 같습니다.

==============================

표: 사용자

• id(클라이언트)

==============================

표: 알림

• id(클라이언트)
• user_id(fk, 인덱스됨)
• text_id(fk - 알림)텍스트 표)
• 값(블롭) [텍스트 문자열에 입력할 값 배열 포함]
• 생성된 날짜 시간(날짜 시간)
• 읽기(계속)

[클러스터]색인] => (user_id, createdDateTime)

==============================

표: 알림텍스트

• id(클라이언트)
• text_id(고유 인덱스됨)
• text (varchar) [{새로운 지급 예정: @paymentID, 만기일은 @dueDate}]
• note (varchar, nullable) [개발자용 노트, 정보 열]

저는 또한 알림 시스템을 설계하는 방법을 찾고 있습니다.알림 상태(읽기, 읽지 않음, 삭제, 보관 등)에 관해서는 ENUM에 적합하다고 생각합니다.read, archive, see, dismissed 등 READ와 UNDARD 이외의 두 가지 이상의 상태가 발생할 가능성이 있다고 생각합니다.

이를 통해 요구사항의 변화에 따라 확장할 수 있습니다.

또한 작업 URL 또는 링크를 저장할 필드가 있는 것이 (적어도 저의 경우에는) 타당할 수 있다고 생각합니다.일부 알림은 사용자에게 링크를 따르도록 요구하거나 메시지를 표시할 수 있습니다.

또한 다른 유형을 원하는 경우 알림 유형도 지정하는 것이 좋습니다.시스템 알림(예: 이메일 알림 확인)과 사용자가 요청하는 알림(예: 친구 요청)이 있을 수 있습니다.

제대로 된 알림 시스템을 갖추기 위해서는 최소한의 구조라고 생각합니다.

users
-------------
id
username
password
email

notifications
-------------
id
user_id (fk)
notification_type (enum)
notification_status (enum)
notification_action (link)
notification_text
date_created (timestamp)

표는 다음과 같습니다.

사용자

• userId(정수)
• 전체 이름(VarChar)

알림

• notificationId(정수)
• 생성 날짜(날짜)
• 알림 세부 정보Url(VarChar)
• isRead(볼린)
• 설명(VarChar)
• userId(F.K)

언급URL : https://stackoverflow.com/questions/1887602/facebook-like-notifications-tracking-db-design