Ho esaminato come costruire un sistema di notifica su SE e altrove e mi sono trovato attratto dalla soluzione che è la risposta accettata qui: /programming/9735578/building-a-notification-system che utilizza questa struttura:
╔═════════════╗ ╔═══════════════════╗ ╔════════════════════╗
║notification ║ ║notification_object║ ║notification_change ║
╟─────────────╢ ╟───────────────────╢ ╟────────────────────╢
║ID ║—1:n—→║ID ║—1:n—→║ID ║
║userID ║ ║notificationID ║ ║notificationObjectID║
╚═════════════╝ ║object ║ ║verb ║
╚═══════════════════╝ ║actor ║
╚════════════════════╝Una notifica riguarda qualcosa (oggetto = evento, amicizia ..) che viene modificato (verbo = aggiunto, richiesto ...) da qualcuno (attore) e segnalato all'utente (soggetto). Ecco una struttura di dati normalizzata (anche se ho usato MongoDB). È necessario informare alcuni utenti delle modifiche. Quindi sono le notifiche per utente ... il che significa che se c'erano 100 utenti coinvolti, si generano 100 notifiche.
All'inizio ho pensato di aver capito questo approccio, ma quando ho iniziato a prepararmi per implementarlo mi sono reso conto che apparentemente non lo capisco particolarmente bene. Gli ultimi commenti sulla risposta sono domande di altri utenti che hanno anche avuto difficoltà a comprendere la soluzione.
Non sono sicuro che questo sia il modello che seguirò, ma dato il numero di voti che ha, sono sicuro che mi gioverebbe a comprenderlo , e sicuramente mi piacerebbe saperne di più. Spero che questo possa essere utile anche agli altri che hanno avuto difficoltà a cogliere questa soluzione (per inciso, non ho abbastanza punti internet per lasciare un commento su quella risposta che indirizza a questa domanda, chiunque altro lo faccia!)
Domande
Se ho capito bene, notificationObjectID è una punta chiave esterna alla notification_object tavolo, e notificationID è una chiave esterna che punta alla notifica di tavolo. Sembra che l' oggetto dovrebbe essere una chiave esterna che si riferisce all'ID della voce del database di cui si riferisce la notifica (ad esempio un evento o post specifico), ma non è necessario un altro campo per indicare a quale tabella appartiene quell'ID?
L'autore ha scritto
notification_object.object identifica il tipo di modifica, come una stringa "amicizia" Il riferimento effettivo all'oggetto modificato con i suoi dati extra di cui parlo è in notification_change.notificationObjectID
che non sembra avere senso per me. L'oggetto è una stringa (enum?) E notificationObjectID è una chiave esterna che fa riferimento all'oggetto di cui si riferisce la notifica? Quindi come sono collegati i tavoli medio e destro?
Sembra che la tabella centrale specifichi su quale oggetto (o tipo di oggetto) si tratti della notifica, ad esempio un evento o un post. Possiamo quindi avere molte voci in notification_change che puntano allo stesso tipo di oggetto, il che ci consente di raggruppare le notifiche (come "25 utenti pubblicati sul muro di X) - da qui la relazione 1: n tra la tabella centrale e quella destra.
Ma perché esiste una relazione 1: n tra la tabella di sinistra e quella centrale? Daremo a "25 utenti pubblicati sulla bacheca di Sam" e "Mary ha aggiornato il suo evento" Venerdì Picnic "lo stesso ID di notifica? Se tutte le notifiche per lo stesso utente hanno lo stesso ID di notifica, perché abbiamo bisogno anche della tabella nella sinistra?
Una domanda sulla performance: dire che John pubblica un commento sull'evento picnic di Mary. Sembra che dovremmo fare una ricerca per vedere se esiste già un oggetto notification_ per Mary's Picnic prima di creare la voce notification_change . Questo avrà un impatto negativo sulle prestazioni o non è un problema? Continuando le domande del paragrafo precedente, come potremmo sapere a quale voce di notifica indirizzare l' oggetto_ notifica ?
