Databasmodell för ett meddelandesystem

Människor älskar att kommunicera. Vi skämtar ofta om att alla mjukvarusystem alltid utvecklas till ett meddelandesystem. Den här artikeln kommer att förklara systemkraven och steg för steg tillvägagångssätt för att utforma en datamodell för ett meddelandesystem.

Krav i nötskal

Kärnfunktionen i ett meddelandesystem i en applikation är att skicka aviseringar/meddelanden till en användare eller en uppsättning användare. Vårt system tillåter också att man skickar meddelanden till en användargrupp. Användargrupper kan uppenbarligen bildas på vissa parametrar som åtkomstprivilegier, användarnas geografiska plats, etc.

Det här systemet tillåter mottagare att svara till meddelandena. Den håller också reda på vem som har läst meddelandet och vem som inte har gjort det.

Dessutom har systemet en inbyggd påminnelse mekanism som gör att en avsändare kan skapa en påminnelse och sedan skickar en påminnelse till alla mottagare i enlighet med detta.

Entiteter och relationer

I denna datamodell, user och message är de huvudsakliga enheterna för att lagra användarnas och meddelandens uppgifter.

Kolumner i user tabellen skulle vara användarrelaterade attribut som first_name , last_name , etc.

Några självförklarande kolumner i message tabellen skulle vara subject , message_body , create_date och expiry_date . Jag lägger också till en främmande nyckelkolumn som heter creator_id i den här tabellen som hänvisar till id kolumn för user tabell. Som namnet antyder, betyder det id:t för skaparen av ett meddelande. Eftersom det alltid skulle finnas en skapare för ett meddelande, behåller jag denna kolumn endast i meddelandetabellen. Du kanske undrar varför det finns ett expiry_date kolumn i tabellen. Jag har lagt till den här kolumnen för att hantera påminnelser på ett meddelande. Jag kommer att förklara mer om den här kolumnen senare i den här artikeln.

Den viktigaste tabellen i denna datamodell är message_recipient . Jag skulle säga att hela datamodellen enbart kretsar kring denna tabell. Ett av huvudmålen bakom att skapa denna tabell är att hålla kartläggningen mellan meddelanden och deras mottagare. Alltså recipient_id kolumnen i den här tabellen anger mottagarnas id, och den här kolumnen hänvisar till id-kolumnen för user bord.

När ett meddelande skickas till en mottagare, kommer en post att infogas i den här tabellen med mottagarens id i recipient_id kolumn.

Nu kanske du undrar vad som är recipient_group_id kolumn betyder i denna tabell. Här bör jag först förklara hur denna modell kan utökas till ett krav på att skicka meddelanden till flera mottagare samtidigt.

Skicka meddelande till en grupp

Jag behöver en annan tabell, nämligen group , för att lagra gruppinformation. Eftersom det finns en många-till-många-relation mellan user och group tabeller, dvs en användare kan vara en del av mer än en grupp, kommer jag att skapa en annan tabell som heter user_group .

Till exempel, om en grupp bildas med 25 användare, skulle det finnas 25 poster, en för varje användare, i user_group bord.

Låt oss gå tillbaka till message_recipient tabell. Jag lägger till en referens till primärnyckeln för user_group tabellen till message_recipient tabell. Jag döper den till recipient_group_id . Den här kolumnen kommer att innehålla värdet för användargruppen som meddelandet skickas för.

Nu när ett meddelande skickas till en grupp kommer flera poster att infogas i message_recipient tabell baserad på antalet användare i gruppen och recipient_group_id kommer att loggas mot alla dessa poster.

Låt mig illustrera det ytterligare med ett exempel. Anta att ett meddelande skickas till en grupp på 10 personer. I det här fallet, totalt 10 poster, en för varje recipient_group_id i gruppen, infogas i message_recipient bord.

Observera att om meddelandet skickas till en användare, inte en grupp, är recipient_group_id kolumnen förblir tom. I det här fallet, det direkta user_id kommer att loggas under recipient_id kolumn.

Jag kommer att lägga till ytterligare en kolumn som heter is_read i tabellen för att hålla en flagga mot en meddelandeanvändare som anger om meddelandet läses av användaren eller inte.

Unik nyckel in message_recipient tabell – Det bör finnas en sammansatt unik nyckel i kolumnerna message_id , recipient_id och recipient_group_id , för att säkerställa att det bara finns en post för en unik kombination av dessa kolumner.

Jag behåller is_active kolumnen i alla tabeller, förutom meddelande- och meddelandemottagare-tabellerna, för att möjliggöra en "mjuk borttagning" av poster. Eftersom jag har lagt till ett expiry_date kolumnen i meddelandetabellen, en is_active kolumn behövs inte. Dessutom behövs inte den här kolumnen i message_recipient tabell eftersom ett meddelande inte kan återställas direkt när det väl har skickats. Men man kan göra den inaktiv genom att uppdatera expiry_date för meddelandet till ett datum i det förflutna.

Svara på ett meddelande

Anta nu att systemet tillåter användare att svara på mottagna meddelanden. Jag utökar samma tabell message för att tillgodose detta krav istället för att skapa en ny tabell för svar. Jag kommer att lägga till en kolumn som heter parent_message_id att upprätta en hierarkisk relation mellan meddelanden. Jag kommer att infoga en ny post för svarsmeddelande och uppdatera parent_message_id kolumnen för svarsmeddelanden. Denna modell stöder n-nivå av hierarkisk relation, dvs svar på svarsmeddelande kan också spåras genom denna modell.

Dashboard för att se "Läs %" av varje meddelande

is_read flaggan loggas mot varje meddelandeanvändarpost. Värdet för denna flagga förblir NOLL tills meddelandet läses av användaren. Det kommer att uppdateras till ONE så snart meddelandet läses av användaren. Baserat på kolumnvärdet kan man bestämma "läs %" för ett meddelande som skickas till en grupp.

Låt mig skriva ett exempel på SQL för att hämta en sådan rapport:

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);

Påminnelsemekanism

För en påminnelsefunktion kommer jag att lägga till följande kolumner i meddelandetabellen:

• Is_reminder – Den här kolumnen flaggar om en påminnelse krävs för meddelandet eller inte.
• Reminder_frequency_id – Den här kolumnen anger påminnelsens frekvens. Ska det vara dagligen eller veckovis?
• Next_remind_date – Den här kolumnen innehåller datumet då nästa påminnelse behöver skickas. Påminnelsen kommer att skickas next_remind_date för de användare för vilka flaggan "är_läs" fortfarande är NOLL. Ett nytt värde för denna kolumn kommer att beräknas varje gång en påminnelse skickas.
• Expiry_date – Den här kolumnen är slutdatumet när påminnelser inte längre kommer att skickas till användare.

Beräkning av next_remind_date skulle vara som följer – Anta att ett meddelande skickas till användare den 14/9, måndag med 10/5 som utgångsdatum för det. Meddelandet skickas med en veckovis frekvens av påminnelser. I det här fallet kommer påminnelser att skickas till användare den 21/9 och 28/9 för att svara på dem på e-post, och en sista gång den 10/5 för att uppmana dem att svara inom de närmaste 24 timmarna.

Slutlig datamodell

Slutsats

En av de bästa användningarna av detta meddelandesystem är att skicka meddelanden till användare som har varit inaktiva i systemet under en längre tid. Dessa aviseringar kan skickas med en påminnelsemekanism aktiverad, och aviseringar kommer att skickas till användare tills användarna svarar på aviseringen. Användare kommer att avaktiveras på och efter utgångsdatumet om inget svar på aviseringarna tas emot från dem.

Jag tänkte bygga en datamodell för ett fullt fungerande meddelandesystem, som kan passas in i en mängd olika system för att skicka meddelanden/aviseringar. Dela gärna med dig av dina åsikter/insatser/kommentarer om artikeln.