Zastanawiałem się, jak zbudować system powiadomień na SE i gdzie indziej i znalazłem pociąg do rozwiązania, które jest akceptowaną odpowiedzią tutaj: /programming/9735578/building-a-notification-system, który używa ta struktura:
╔═════════════╗ ╔═══════════════════╗ ╔════════════════════╗
║notification ║ ║notification_object║ ║notification_change ║
╟─────────────╢ ╟───────────────────╢ ╟────────────────────╢
║ID ║—1:n—→║ID ║—1:n—→║ID ║
║userID ║ ║notificationID ║ ║notificationObjectID║
╚═════════════╝ ║object ║ ║verb ║
╚═══════════════════╝ ║actor ║
╚════════════════════╝Powiadomienie dotyczy zmiany (obiektu = zdarzenia, przyjaźni ...) przez kogoś (aktora) i zgłoszenia go użytkownikowi (podmiotowi). Oto znormalizowana struktura danych (chociaż korzystałem z MongoDB). Musisz powiadomić niektórych użytkowników o zmianach. Tak więc są to powiadomienia dla poszczególnych użytkowników .. co oznacza, że jeśli w grę wchodzi 100 użytkowników, generujesz 100 powiadomień.
Na początku myślałem, że zrozumiałem to podejście, ale kiedy zacząłem przygotowywać się do jego wdrożenia, zdałem sobie sprawę, że najwyraźniej nie rozumiem go szczególnie dobrze. Ostatnie kilka komentarzy do odpowiedzi to pytania innych użytkowników, którzy również mieli problemy ze zrozumieniem rozwiązania.
Nie jestem pewien, czy to model, za którym skończę, ale biorąc pod uwagę liczbę pozytywnych opinii, jestem pewien, że zrozumiałoby to go , a na pewno chciałbym dowiedzieć się więcej. Mam nadzieję, że przyda się to także innym, którzy mieli problem z uchwyceniem tego rozwiązania (nawiasem mówiąc, nie mam wystarczającej liczby punktów internetowych, aby skomentować tę odpowiedź kierując do tego pytania, proszę o to inne osoby!)
pytania
Jeśli dobrze to rozumiem, powiadomienieObjectID to klucz obcy wskazujący na tabelę powiadomienia_obiekt , a identyfikator powiadomienia to klucz obcy wskazujący na tabelę powiadomień . Wygląda jak przedmiot powinien być kluczem obcym odnoszącym się do identyfikatora wpisu bazy danych, którego dotyczy powiadomienie (np. Określone zdarzenie lub post), ale czy nie potrzebujemy wtedy innego pola wskazującego, do której tabeli należy ten identyfikator?
Autor napisał
notice_object.object identyfikuje typ zmiany, np. ciąg „przyjaźń” Rzeczywiste odniesienie do zmienionego obiektu z jego dodatkowymi danymi, o których mówię, znajduje się w powiadomienia_change.notificationObjectID
co nie wydaje mi się mieć sensu. Obiekt jest ciągiem znaków (enum?), A identyfikatorObiektuObjectID to klucz obcy odnoszący się do obiektu, o którym jest powiadomienie? Jak w ogóle są połączone środkowe i prawe stoły?
Wygląda na to, że środkowa tabela określa, o jakim obiekcie (lub typie obiektu) chodzi o powiadomienie, np. Zdarzenie lub post. Możemy wtedy mieć wiele wpisów w powiadomienia_zmiany, które wskazują na ten sam typ obiektu, co pozwala nam grupować powiadomienia (np. „25 użytkowników opublikowanych na ścianie X) - stąd relacja 1: n między środkową i prawą tabelą.
Ale dlaczego istnieje związek 1: n między lewym a środkowym stołem? Czy nadamy „25 użytkownikom umieszczonym na ścianie Sama” i „Mary zaktualizowała swoje wydarzenie„ Piątek piknik ”ten sam identyfikator powiadomienia? Jeśli wszystkie powiadomienia dla tego samego użytkownika mają ten sam identyfikator powiadomienia, dlaczego potrzebujemy tabeli lewo?
Pytanie o wydajność - powiedzmy, że John komentuje piknik Mary. Wygląda na to, że musielibyśmy sprawdzić, czy obiekt powiadomień istnieje już dla Mary's Picnic, zanim utworzymy wpis powiadomienia_zmiany . Czy wpłynie to negatywnie na wydajność, czy może nie będzie problemu? Kontynuując pytania z poprzedniego akapitu, skąd mielibyśmy wiedzieć, do którego powiadomienia należy skierować obiekt_zadania ?
źródło
