Modelo de base de datos para un sistema de mensajería

A la gente le encanta comunicarse. A menudo bromeamos con que cualquier sistema de software siempre se convierte en un sistema de mensajería. Este artículo explicará los requisitos del sistema y el enfoque paso a paso para diseñar un modelo de datos para un sistema de mensajería.

Requisitos en pocas palabras

La funcionalidad principal de un sistema de mensajería en una aplicación es enviar notificaciones/mensajes a un usuario o a un conjunto de usuarios. Nuestro sistema también permite enviar mensajes a un grupo de usuarios. Obviamente, los grupos de usuarios se pueden formar en función de algunos parámetros, como los privilegios de acceso, la ubicación geográfica de los usuarios, etc.

Este sistema permite que los receptores respondan a los mensajes. También realiza un seguimiento de quién ha leído el mensaje y quién no.

Además, el sistema tiene un recordatorio incorporado mecanismo que permite a un remitente crear un recordatorio y luego envía un recordatorio a todos los receptores en consecuencia.

Entidades y Relaciones

En este modelo de datos, user y message son las principales entidades para almacenar los detalles de los usuarios y los mensajes.

Columnas en el user la tabla serían atributos relacionados con el usuario como first_name , last_name , etc.

Algunas columnas autoexplicativas en el message la tabla sería subject , message_body , create_date y expiry_date . También agrego una columna de clave externa llamada creator_id en esta tabla que se refiere al id columna de user mesa. Como su nombre indica, significa la identificación del creador de un mensaje. Dado que siempre habrá un creador para un mensaje, mantengo esta columna solo en la tabla de mensajes. Quizás se pregunte por qué hay una expiry_date columna en la tabla. He agregado esta columna para administrar recordatorios en un mensaje. Explicaré más sobre esta columna más adelante en este artículo.

La tabla más importante en este modelo de datos es message_recipient . Diría que todo el modelo de datos gira solo en torno a esta tabla. Uno de los principales objetivos detrás de la creación de esta tabla es mantener el mapeo entre los mensajes y sus destinatarios. Por lo tanto, el recipient_id La columna en esta tabla significa los ID de los destinatarios, y esta columna se refiere a la columna de ID de user mesa.

Cuando se envía un mensaje a un destinatario, se insertará un registro en esta tabla con la identificación del destinatario en el recipient_id columna.

Ahora puede que se pregunte cuál es el recipient_group_id columna significa en esta tabla. Aquí, primero debo explicar cómo este modelo puede extenderse a un requisito de enviar mensajes a múltiples destinatarios a la vez.

Enviar mensaje a un grupo

Necesito otra tabla, a saber, group , para guardar los detalles del grupo. Dado que existe una relación de muchos a muchos entre el user y group tablas, es decir, un usuario puede ser parte de más de un grupo, crearé otra tabla llamada user_group .

Por ejemplo, si se forma un grupo con 25 usuarios, habría 25 registros, uno para cada usuario, en el user_group mesa.

Volvamos al message_recipient mesa. Agrego una referencia a la clave principal del user_group tabla en el message_recipient mesa. Lo llamo recipient_group_id . Esta columna contendrá el valor del grupo de usuarios para el que se envía el mensaje.

Ahora, siempre que se envíe un mensaje a un grupo, se insertarán varios registros en el message_recipient tabla basada en la cantidad de usuarios en el grupo y el recipient_group_id se registrará en consecuencia contra todos esos registros.

Permítanme ilustrarlo más con un ejemplo. Supongamos que se envía un mensaje a un grupo de 10 personas. En este caso, un total de 10 registros, uno para cada recipient_group_id del grupo, se insertará en el message_recipient mesa.

Tenga en cuenta que si el mensaje se envía a un usuario, no a un grupo, el recipient_group_id la columna permanece vacía. En este caso, el user_id directo se registrará bajo el recipient_id columna.

Agregaré una columna más llamada is_read en la tabla para mantener una bandera contra un mensaje-usuario que indica si el usuario lee o no el mensaje.

Entrada de clave única message_recipient tabla:debe haber una clave única compuesta en las columnas message_id , recipient_id y recipient_group_id , para garantizar que solo exista un registro para una combinación única de estas columnas.

Mantengo el is_active columna en todas las tablas, excepto las tablas message y message_recipient, para habilitar una 'eliminación temporal' de registros. Dado que agregué una expiry_date columna en la tabla de mensajes, un is_active la columna no es necesaria. Además, esta columna no es necesaria en el message_recipient porque un mensaje no se puede revertir directamente una vez que se envía. Sin embargo, se puede desactivar actualizando expiry_date para el mensaje a una fecha en el pasado.

Responder a un mensaje

Ahora suponga que el sistema permite a los usuarios responder a los mensajes recibidos. Extiendo la misma tabla message para satisfacer este requisito en lugar de crear una nueva tabla para las respuestas. Agregaré una columna llamada parent_message_id establecer una relación jerárquica entre los mensajes. Insertaré un nuevo registro para el mensaje de respuesta y actualizaré el parent_message_id columna para mensajes de respuesta. Este modelo admite n niveles de relación jerárquica, es decir, la respuesta en el mensaje de respuesta también se puede rastrear a través de este modelo.

Panel para ver el '% de lectura' de cada mensaje

El is_read se registra en cada registro de usuario de mensaje. El valor de este indicador sigue siendo CERO hasta que el usuario lee el mensaje. Se actualizará a UNO tan pronto como el usuario lea el mensaje. Según el valor de la columna, se puede determinar el "% de lectura" de un mensaje que se envía a un grupo.

Permítanme escribir un ejemplo de SQL para obtener dicho informe:

SELECT msg.subject, sent_to, 
       msg.create_date, (summ / countt) * 100 AS Read_Per
FROM (SELECT msg.subject, grp.name as sent_to,  msg.create_date, 
      SUM (is_read) AS summ, COUNT (is_read) AS countt
      FROM message_recipient msgrec,  message msg,  
           user_group ug,  group grp
      WHERE  msgrec.message_id = msg.id
      AND msgrec.recipient_group_id = ug.id
      AND ug.GROUP_ID = grp.id
      AND msgrec.recipient_group_id IS NOT NULL
      GROUP BY msg.subject, grp.name, msg.create_date
      UNION
      SELECT msg.subject, u.first_name || ' ' || u.last_name as sent_to,
      msg.create_date, SUM (is_read) AS summ, COUNT (is_read) AS countt
      FROM message_recipient msgrec, MESSAGE msg,  user u
      WHERE msgrec.message_id = msg.id
      AND msgrec.recipient_id = u.id
      AND msgrec.recipient_group_id IS NULL
      GROUP BY msg.subject, name, msg.create_date);

Mecanismo de recordatorio

Para una función de recordatorio, agregaré las siguientes columnas en la tabla de mensajes:

• Is_reminder – Esta columna indica si se requiere o no un recordatorio para el mensaje.
• Reminder_frequency_id – Esta columna indica la frecuencia del recordatorio. ¿Debería ser diario o semanal?
• Next_remind_date – Esta columna contiene la fecha en que se debe enviar el próximo recordatorio. El recordatorio se enviará el next_remind_date para los usuarios para quienes el indicador 'is_read' sigue siendo CERO. Se calculará un nuevo valor para esta columna cada vez que se envíe un recordatorio.
• Expiry_date – Esta columna es la fecha límite en la que ya no se enviarán recordatorios a los usuarios.

Cálculo de la next_remind_date sería el siguiente:supongamos que se envía un mensaje a los usuarios el lunes 14 de septiembre con el 5 de octubre como fecha de vencimiento. El mensaje se envía con una frecuencia semanal de recordatorios. En este caso, se enviarán recordatorios a los usuarios el 21 y el 28 de septiembre para responderles por correo electrónico, y una última vez el 5 de octubre para instarles a que respondan en las próximas 24 horas.

Modelo de datos finales

Conclusión

Uno de los mejores usos de este sistema de mensajería es enviar notificaciones a los usuarios que han estado inactivos en el sistema durante mucho tiempo. Estas notificaciones se pueden enviar con un mecanismo de recordatorio habilitado y las notificaciones se enviarán a los usuarios hasta que los usuarios respondan a la notificación. Los usuarios se desactivarán a partir de la fecha de vencimiento si no se recibe ninguna respuesta a las notificaciones.

Tenía la intención de construir un modelo de datos para un sistema de mensajería completamente funcional, que puede encajar en una variedad de sistemas para enviar mensajes/notificaciones. Siéntase libre de compartir sus puntos de vista/entradas/comentarios sobre el artículo.