Databázový model pro systém zasílání zpráv

Lidé rádi komunikují. Často vtipkujeme, že jakýkoli softwarový systém se vždy vyvine v systém zasílání zpráv. Tento článek vysvětlí systémové požadavky a postupný přístup k návrhu datového modelu pro systém zasílání zpráv.

Požadavky ve zkratce

Základní funkcí systému zasílání zpráv v aplikaci je odesílání oznámení/zpráv uživateli nebo skupině uživatelů. Náš systém také umožňuje posílat zprávy skupině uživatelů. Skupiny uživatelů lze samozřejmě vytvářet na základě některých parametrů, jako jsou přístupová oprávnění, geografická poloha uživatelů atd.

Tento systém umožňuje přijímačům reagovat ke zprávám. Také sleduje, kdo si zprávu přečetl a kdo ne.

Kromě toho má systém vestavěné připomenutí mechanismus, který odesílateli umožňuje vytvořit upomínku a následně podle toho odešle upomínku všem příjemcům.

Entity a vztahy

V tomto datovém modelu user a message jsou hlavními entitami pro ukládání podrobností o uživatelích a zprávách.

Sloupce v user tabulka by byly atributy související s uživatelem jako first_name , last_name , atd.

Některé samovysvětlující sloupce ve message tabulka by byla subject , message_body , create_date a expiry_date . Přidávám také sloupec cizího klíče s názvem creator_id v této tabulce, která odkazuje na id sloupec user stůl. Jak jeho název napovídá, znamená id tvůrce zprávy. Vzhledem k tomu, že pro zprávu by byl vždy jeden tvůrce, ponechám tento sloupec pouze v tabulce zpráv. Možná se divíte, proč existuje expiry_date sloupec v tabulce. Tento sloupec jsem přidal pro správu připomenutí ve zprávě. Více o tomto sloupci vysvětlím později v tomto článku.

Nejdůležitější tabulka v tomto datovém modelu je message_recipient . Řekl bych, že celý datový model se točí pouze kolem této tabulky. Jedním z hlavních cílů za vytvořením této tabulky je udržet mapování mezi zprávami a jejich příjemci. Tedy recipient_id sloupec v této tabulce označuje ID příjemců a tento sloupec odkazuje na sloupec ID user tabulka.

Když je zpráva odeslána jednomu příjemci, bude do této tabulky vložen jeden záznam s ID příjemce v recipient_id sloupec.

Možná vás teď zajímá, co je recipient_group_id sloupec v této tabulce znamená. Zde bych měl nejprve vysvětlit, jak lze tento model rozšířit na požadavek zasílání zpráv více příjemcům najednou.

Odeslání zprávy skupině

Potřebuji další tabulku, konkrétně group , chcete-li uchovat podrobnosti o skupině. Protože mezi user a group tabulky, tj. uživatel může být součástí více skupin, vytvořím další tabulku s názvem user_group .

Pokud je například vytvořena skupina s 25 uživateli, bude ve skupině user_group tabulka.

Vraťme se k message_recipient stůl. Přidávám odkaz na primární klíč skupiny user_group tabulky do message_recipient stůl. Pojmenuji to recipient_group_id . Tento sloupec bude obsahovat hodnotu uživatelské skupiny, pro kterou je zpráva odeslána.

Nyní, kdykoli je skupině odeslána zpráva, bude do message_recipient tabulka založená na počtu uživatelů ve skupině a recipient_group_id bude odpovídajícím způsobem zaprotokolován proti všem těmto záznamům.

Dovolte mi to dále ilustrovat na příkladu. Předpokládejme, že je zpráva odeslána skupině 10 lidí. V tomto případě celkem 10 záznamů, jeden pro každý recipient_group_id skupiny, bude vložen do message_recipient tabulka.

Upozorňujeme, že pokud je zpráva odeslána uživateli, nikoli skupině, pak recipient_group_id sloupec zůstane prázdný. V tomto případě přímé user_id bude přihlášen pod recipient_id sloupec.

Přidám ještě jeden sloupec s názvem is_read do tabulky, aby držel příznak proti uživateli zprávy, který značí, zda uživatel zprávu čte nebo ne.

Jedinečný klíč v message_recipient tabulka – Ve sloupcích message_id by měl být složený jedinečný klíč , recipient_id a recipient_group_id , abyste zajistili, že pro jedinečnou kombinaci těchto sloupců existuje pouze jeden záznam.

Ponechávám is_active sloupec ve všech tabulkách, kromě tabulek message a message_recipient, aby bylo možné „měkké odstranění“ záznamů. Protože jsem přidal expiry_date sloupec v tabulce zpráv is_active sloupec není potřeba. Navíc tento sloupec není potřeba v message_recipient tabulka, protože zprávu nelze po odeslání vrátit přímo. Je však možné jej deaktivovat aktualizací expiry_date pro zprávu k datu v minulosti.

Odpovídání na zprávu

Nyní předpokládejme, že systém umožňuje uživatelům odpovídat na přijaté zprávy. Rozšiřuji stejnou tabulku message uspokojit tento požadavek namísto vytváření nové tabulky pro odpovědi. Přidám jeden sloupec s názvem parent_message_id vytvořit hierarchický vztah mezi zprávami. Vložím nový záznam pro odpověď na zprávu a aktualizuji parent_message_id sloupec pro odpovědi na zprávy. Tento model podporuje n-úroveň hierarchického vztahu, tj. prostřednictvím tohoto modelu lze také sledovat odpověď na zprávu s odpovědí.

Panel pro zobrazení „přečtených %“ každé zprávy

is_read příznak se zaprotokoluje u každého záznamu uživatele zprávy. Hodnota tohoto příznaku zůstává NULA, dokud si uživatel zprávu nepřečte. Jakmile si uživatel zprávu přečte, bude aktualizována na ONE. Na základě hodnoty sloupce lze určit ‚přečtené %‘ pro zprávu, která je odeslána skupině.

Dovolte mi napsat ukázkový SQL pro načtení takové zprávy:

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

Mechanismus připomenutí

Pro funkci připomenutí přidám do tabulky zpráv následující sloupce:

• Is_reminder – Tento sloupec označuje, zda je pro zprávu vyžadováno připomenutí.
• Reminder_frequency_id – Tento sloupec označuje frekvenci upomínky. Mělo by to být na denní nebo týdenní bázi?
• Next_remind_date – Tento sloupec obsahuje datum, kdy je třeba odeslat další upomínku. Připomenutí bude odesláno next_remind_date pro uživatele, pro které je příznak „is_read“ stále NULA. Při každém odeslání upomínky se vypočítá nová hodnota pro tento sloupec.
• Expiry_date – Tento sloupec představuje konečné datum, kdy již nebudou uživatelům zasílána upomínky.

Výpočet next_remind_date by bylo následující – Předpokládejme, že jedna zpráva je odeslána uživatelům 14. září v pondělí s datem vypršení platnosti 10. září. Zpráva je odesílána s týdenní frekvencí připomenutí. V tomto případě budou uživatelům 21. a 28. září zaslána připomenutí, aby jim odpověděli e-mailem, a naposledy 5. 10. s výzvou, aby odpověděli během následujících 24 hodin.

Konečný datový model

Závěr

Jedním z nejlepších využití tohoto systému zasílání zpráv je zasílání upozornění uživatelům, kteří byli v systému dlouhou dobu neaktivní. Tato upozornění lze odesílat s aktivovaným mechanismem připomenutí a upozornění budou zasílána uživatelům, dokud uživatelé na upozornění nezareagují. Uživatelé budou deaktivováni po datu vypršení platnosti, pokud od nich neobdržíte žádnou odpověď na oznámení.

Měl jsem v úmyslu vytvořit datový model pro plně funkční systém zasílání zpráv, který lze zapojit do různých systémů pro odesílání zpráv/upozornění. Neváhejte se podělit o své názory/vstupy/komentáře k článku.