¿Cómo creo el sistema "Watch"? Buscando las mejores prácticas

Question

Tengo un sitio comunitario bastante complejo (en php/mysql) con una cantidad de "cosas" que los usuarios registrados pueden "mirar".

"cosas" son: Mensajes, comentarios, actualizaciones de eventos, cambios de estado de usuario, etc. Por lo menos 10 tipos diferentes de "cosas" están disponibles y un usuario puede ver "cosas" de cualquier otro usuario (Piense facebook)

"Ver" significa: un usuario puede ver cualquier "cosa" y ver un feed de todas las actualizaciones/adiciones a cada "cosa" a través de todo tipo de "cosas".

he construido una aplicación similar con muchos menos "cosas" que pueden ser vistos y mi configuración es básicamente esto:

'relojes' campos de la tabla: ID, ID de usuario, itemId [id en la tabla extranjera] , itemClass [ID de referencia de la tabla extranjera]

Un usuario podría agregar un 'reloj', se creó un registro en la tabla 'relojes' y luego sondearíamos esa tabla (y la almacenaríamos en caché) para que navegaran nosotros notaba (en la interfaz de usuario) si ya estaban viendo un elemento en particular o no, MÁS podían ver y administrar una lista de todo el sistema que estaban viendo. Bastante simple.

Entonces, (después de esa larga introducción), este sitio de comunidad que estamos construyendo necesitará escalar más dramáticamente. Miles de usuarios verán cientos de "cosas" y tendremos que sondear no solo la tabla de "relojes" per se, sino también cada mesa extranjera, unirnos para obtener los detalles que llenen el feed de visualización de cada usuario.

Si no está seguro de lo que quiero decir, solo piense en el feed de amigos de Facebook que tiene en su página de inicio de Facebook. ¿Cómo se actualiza eso sin ejecutar toneladas de consultas?

Answer 1

lo mejor que puede hacer en términos de escalabilidad e ignorar las reglas de normalización (que a veces tiene que hacer por motivos de rendimiento) sería almacenar los relojes en una tabla como la que ya tiene, pero también agregar una columna de TEXTO a las tablas de contenido donde almacena de forma delimitada todas las identificaciones de los usuarios que miran ese artículo.

cuando se actualiza el elemento, usted tiene una lista práctica de personas preconfiguradas para notificar sin gastos adicionales.

y cuando un usuario quiere ver lo que está viendo, tiene sus tablas normalizadas eficientes.

vbulletin hace esto, creo, para hacer un seguimiento de quién ha leído un hilo en particular.

Answer 2

Cuando alguien hace una actualización, podría notificar a todos los "observadores" que algo ha cambiado, dándole una referencia para buscar. Entonces cuando inicio sesión, el sistema consulta mi tabla y descubre que alguna "cosa" hizo una actualización. A continuación, recupera esa actualización y me la muestra en la página. Es algo así como un modelo de publicación/suscripción.

EDIT (para incluir mi comentario):

Cada usuario tendría una fila en una watch_table asociado con ellos. Así que me adjunté como observadora a las actualizaciones de estado de mi novia, almacenadas en su registro de usuario. Luego, cuando se actualice, recorra su lista de observadores, colocando un registro en el registro de cada observador en el watch_table. Entonces cuando inicio sesión, mi registro watch_table es consultado, y veo en la interfaz de usuario que su estado se actualizó.

Lo anterior está usando algunas semánticas de las actualizaciones de estado de Facebook.

Answer 3

El otro enfoque de su sondeo sería configurar su sistema para que se observaran "actualizaciones de reloj" después de la creación de un elemento.

La lógica sería:

1. mensaje se crea
2. Como paso final en la creación de correos, una consulta se ejecuta en los relojes mesa para observar a la gente para los nuevos Mensajes
3. como relojes se encuentra que escribe una entrada a la "actividad" de esos usuarios o al feed de visualización .

Answer 4

En cada operación de guardado, deberá determinar si se trata de un elemento "mirado" y registrarlo en una nueva tabla. tendrá que guardar, qué tipo de elemento es, quién lo está mirando, etc. cuando necesite mostrar los elementos observados, consultará esta nueva tabla que será rápida.

Answer 5

Puede usar las fechas para hacer un seguimiento de lo que el usuario ha visto o no. Cuando un usuario inicia sesión, inicia sesión en una fecha/hora determinada. Cuando el usuario inicie sesión de nuevo más tarde, puede ejecutar consultas sobre todas las "cosas" que están siendo "vistas" por ese usuario que sean más recientes que la última fecha de inicio de sesión. Esto crearía la lista de lectores sobre la marcha y no en cada actualización de "cosas".

Answer 6

En términos de patrones, una cosa a tener en cuenta aquí es el patrón clásico de "Escucha"/"Notificación de evento"/"Observador". Desea asociar a las personas que están generando los eventos y a las personas que los escuchan, para que no tenga que modificar los generadores de eventos después de agregar un nuevo oyente.

De hecho, disparando una notificación "¡He cambiado!" o "¡Soy una nueva publicación!" después de una modificación relevante del objeto observable, y mirando en una tabla que registró a todos los oyentes, parece un buen enfoque.

Answer 7

Eche un vistazo al servicio de notificaciones SQL de MSFT. Aunque ya no es compatible con SQL Sver 2008, su documentación describe un motor de notificación robusto. Algo que puede, o no puede, querer modelar, según sus necesidades.