database design - examples - ¿Flujos de actividad/feeds, para desnormalizar o no?

industry database models

Question

Sé que muchas veces me han preguntado las variaciones de esta pregunta (y las he leído, 2 de ellas son: 1 , 2 ) , pero simplemente no puedo entender nada que parezca la solución correcta.

Todo ha sido sugerido desde muchas a muchas relaciones, a fanout, a asociaciones polimórficas, a soluciones NoSQL, a colas de mensajes, a desnormalización y combinaciones de todas ellas.

Sé que esta pregunta es muy situacional, así que explicaré brevemente la mía:

• Muchas actividades que provocan muchos eventos.
  • Seguir, crear, gustar, comentar, editar, borrar, etc.
• Un usuario puede seguir la actividad de otro usuario (los eventos que desencadenan) .
• Los eventos más solicitados serán los eventos más recientes.
  • Se desea la posibilidad de ver eventos pasados.
• No se desea ordenar ni buscar el feed después de ordenar por fecha de desc.
• La escalabilidad es una preocupación (rendimiento y capacidad de expansión) .

Por el momento, terminé yendo con una configuración desnormalizada que básicamente se compone de una tabla de eventos que consta de: id , date , user_id root_id , action , root_id , object_id , object , data .

user_id es la persona que desencadenó el evento.
action es la acción.
root_id es el usuario al object pertenece el object .
siendo el objeto el tipo de objeto.
data contienen la cantidad mínima de información necesaria para representar el evento en el flujo de un usuario.

Luego, para obtener los eventos deseados, solo tomo todas las filas en las que el user_id es la ID de un usuario que está siendo seguido por la secuencia a la que estamos agarrando.

Funciona , pero la desnormalización se siente mal. Las asociaciones polimórficas también lo parecen. El fanout parece estar en un punto intermedio, pero se siente muy desordenado.

Con toda mi búsqueda sobre el problema y la lectura de las numerosas preguntas aquí en SO, simplemente no puedo hacer clic en nada y me siento como la solución correcta.

Cualquier experiencia, conocimiento o ayuda que alguien pueda ofrecer es muy apreciada. Gracias.

Answer 1

Creo que usar una combinación de NoSQL / Memcached puede satisfacer sus necesidades. Por favor, vea esta URL para más ideas:

http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture

Answer 2

Nunca he tratado con feeds de actividad social, pero según su descripción son muy similares a mantener registros de actividad empresarial complicados.

Personalmente, es un caso que tiendo a administrar con tablas separadas para los tipos de actividad aplicables, una tabla de revisiones / registros para cada uno de estos tipos, y cada uno de estos últimos con una referencia a una tabla de registros de eventos más central.

Este último permite crear la fuente y se parece mucho a la solución que se te ocurrió: event_id, event_at, event_name, event_by, event_summary, event_type. (El campo event_type es un varchar que contiene el nombre de la tabla u objeto).

Es probable que no necesite mantener el historial de todo en su caso (seguramente esto sea menos apropiado para solicitudes de amigos que para ventas y movimientos de existencias), pero mantiene algún tipo de tabla central de registros de eventos (además de otras tablas aplicables a tener los datos normalizados a la mano) es, creo, el enfoque correcto.

Puede obtener algunas ideas interesantes si consulta las preguntas relacionadas con el registro de auditoría:

https://.com/search?q=audit+log