He estado buscando cómo construir un sistema de notificación en SE y en otros lugares y me encontré atraído por la solución que es la respuesta aceptada aquí: /programming/9735578/building-a-notification-system que utiliza esta estructura:
╔═════════════╗ ╔═══════════════════╗ ╔════════════════════╗
║notification ║ ║notification_object║ ║notification_change ║
╟─────────────╢ ╟───────────────────╢ ╟────────────────────╢
║ID ║—1:n—→║ID ║—1:n—→║ID ║
║userID ║ ║notificationID ║ ║notificationObjectID║
╚═════════════╝ ║object ║ ║verb ║
╚═══════════════════╝ ║actor ║
╚════════════════════╝Una notificación es sobre algo (objeto = evento, amistad ...) que alguien (actor) le ha cambiado (verbo = agregado, solicitado ...) y lo ha informado al usuario (sujeto). Aquí hay una estructura de datos normalizada (aunque he usado MongoDB). Debe notificar a ciertos usuarios sobre los cambios. Entonces, son notificaciones por usuario ... lo que significa que si hubiera 100 usuarios involucrados, generaría 100 notificaciones.
Al principio pensé que entendía este enfoque, pero cuando comencé a prepararme para implementarlo, me di cuenta de que aparentemente no lo entiendo particularmente bien. Los últimos comentarios sobre la respuesta son preguntas de otros usuarios que también han tenido problemas para comprender la solución.
No estoy seguro de si este es el modelo que terminaré siguiendo, pero dada la cantidad de votos a favor que tiene, estoy seguro de que me beneficiaría entenderlo , y ciertamente me gustaría aprender más. Espero que esto también sea útil para otras personas que han tenido problemas para comprender esta solución (por cierto, no tengo suficientes puntos de Internet para dejar un comentario sobre esa respuesta que dirija a esta pregunta, ¡alguien más, por favor!)
Preguntas
Si lo entiendo bien, notifyObjectID es una clave externa que apunta a la tabla notificación_objeto , y notifyID es una clave externa que apunta a la tabla de notificación . Parece que el objeto debería ser una clave externa que se refiera a la ID de la entrada de la base de datos de la que trata la notificación (por ejemplo, un evento o publicación específica), pero ¿no necesitamos entonces otro campo para indicar a qué tabla pertenece esa ID?
El autor escribió
notify_object.object identifica el tipo de cambio, como una cadena "amistad" La referencia real al objeto cambiado con sus datos adicionales de los que hablo está en notify_change.notificationObjectID
lo cual no parece tener sentido para mí. El objeto es una cadena (¿enumeración?) Y notifyObjectID es una clave externa que se refiere al objeto del que trata la notificación? Entonces, ¿cómo están conectadas las tablas del medio y la derecha?
Parece que la tabla central especifica de qué objeto (o tipo de objeto) trata la notificación, por ejemplo, un evento o publicación. Entonces podemos tener muchas entradas en notify_change que apuntan al mismo tipo de objeto, lo que nos permite agrupar notificaciones (como "25 usuarios publicados en el muro de X), de ahí la relación 1: n entre las tablas del medio y la derecha.
Pero, ¿por qué hay una relación 1: n entre las tablas izquierda y media? ¿Vamos a dar a "25 usuarios publicados en el muro de Sam" y "Mary actualizó su evento" Viernes Picnic "con la misma ID de notificación? Si todas las notificaciones para el mismo usuario tienen la misma ID de notificación, ¿por qué necesitamos la tabla en el ¿izquierda?
Una pregunta de rendimiento: digamos que John publica un comentario sobre el evento de picnic de Mary. Parece que tendríamos que hacer una búsqueda para ver si ya existe un objeto de notificación para Mary's Picnic antes de crear la entrada de notificación de cambio . ¿Esto tendrá un impacto negativo en el rendimiento o no es un problema? Continuando con las preguntas del párrafo anterior, ¿cómo sabríamos a qué entrada de notificación dirigir el objeto de notificación ?
