Модел на база данни за система за съобщения

Хората обичат да общуват. Често се шегуваме, че всяка софтуерна система винаги еволюира в система за съобщения. Тази статия ще обясни системните изисквания и подхода стъпка по стъпка за проектиране на модел на данни за система за съобщения.

Изисквания накратко

Основната функционалност на системата за съобщения в приложение е да изпраща известия/съобщения на потребител или набор от потребители. Нашата система също така позволява да се изпращат съобщения до потребителска група. Потребителски групи очевидно могат да се формират по някои параметри като привилегии за достъп, географско местоположение на потребителите и т.н.

Тази система позволява на приемниците да отговарят към съобщенията. Той също така следи кой е прочел съобщението и кой не.

Освен това системата има вграденонапомняне механизъм, който позволява на подателя да създаде напомняне и след това изпраща съответно напомняне до всички получатели.

Обекти и връзки

В този модел на данни user и message са основните обекти за съхраняване на данните за потребителите и съобщенията.

Колони в user таблицата ще бъде атрибути, свързани с потребителя, като first_name , last_name и др.

Някои колони, разбиращи се от само себе си в message таблицата ще бъде subject , message_body , create_date и expiry_date . Добавям и колона за външен ключ, наречена creator_id в тази таблица, която се отнася до id колона на user маса. Както подсказва името му, той означава идентификатора на създателя на съобщение. Тъй като винаги ще има един създател за съобщение, запазвам тази колона само в таблицата със съобщения. Може би се чудите защо има expiry_date колона в таблицата. Добавих тази колона за управление на напомняния за съобщение. Ще обясня повече за тази колона по-късно в тази статия.

Най-важната таблица в този модел на данни е message_recipient . Бих казал, че целият модел на данни се върти само около тази таблица. Една от основните цели зад създаването на тази таблица е да поддържа съпоставянето между съобщенията и техните получатели. Така recipient_id колоната в тази таблица означава идентификаторите на получателите, а тази колона се отнася до колоната с идентификатор на user таблица.

Когато съобщение се изпрати до един получател, един запис ще бъде вмъкнат в тази таблица с идентификатора на получателя в recipient_id колона.

Сега може би се чудите какво е recipient_group_id колона означава в тази таблица. Тук първо трябва да обясня как този модел може да бъде разширен до изискване за изпращане на съобщения до множество получатели наведнъж.

Изпращане на съобщение до група

Имам нужда от друга таблица, а именно group , за да задържите подробности за групата. Тъй като между user и group таблици, т.е. потребител може да бъде част от повече от една група, ще създам друга таблица, наречена user_group .

Например, ако групата е сформирана с 25 потребители, ще има 25 записа, по един за всеки потребител, в user_group таблица.

Нека се върнем към message_recipient маса. Добавям препратка към първичния ключ на user_group таблица в message_recipient маса. Казвам го recipient_group_id . Тази колона ще съдържа стойността на потребителската група, за която е изпратено съобщението.

Сега всеки път, когато се изпрати съобщение до група, множество записи ще бъдат вмъкнати в message_recipient таблица въз основа на броя на потребителите в групата и recipient_group_id ще бъде съответно регистриран спрямо всички тези записи.

Нека го илюстрирам допълнително с пример. Да предположим, че е изпратено съобщение до група от 10 души. В този случай общо 10 записа, по един за всеки recipient_group_id от групата, ще бъдат вмъкнати в message_recipient таблица.

Моля, имайте предвид, че ако съобщението е изпратено до потребител, а не до група, тогава recipient_group_id колоната остава празна. В този случай директният user_id ще бъде регистриран под recipient_id колона.

Ще добавя още една колона, наречена is_read в таблицата, за да държи флаг срещу потребител на съобщение, което означава дали съобщението е прочетено от потребителя или не.

Уникален ключ в message_recipient таблица – Трябва да има съставен уникален ключ в колоните message_id , recipient_id и recipient_group_id , за да се гарантира, че съществува само един запис за уникална комбинация от тези колони.

Поддържам is_active колона във всички таблици, с изключение на таблиците message и message_recipient, за да активирате „меко изтриване“ на записи. Тъй като добавих expiry_date колона в таблицата със съобщения, is_active колона не е необходима. Освен това тази колона не е необходима в message_recipient таблица, тъй като съобщението не може да бъде върнато директно, след като е изпратено. Въпреки това човек може да го направи неактивен чрез актуализиране на expiry_date за съобщението до дата в миналото.

Отговор на съобщение

Сега да предположим, че системата позволява на потребителите да отговарят на получените съобщения. Разширявам същата таблица message за да изпълни това изискване, вместо да създава нова таблица за отговори. Ще добавя една колона, наречена parent_message_id за установяване на йерархична връзка между съобщенията. Ще вмъкна нов запис за съобщение за отговор и ще актуализирам parent_message_id колона за съобщения за отговор. Този модел поддържа n-ниво на йерархична връзка, т.е. отговорът на съобщението за отговор може също да бъде проследен чрез този модел.

Табло за управление за преглед на „прочетени %“ от всяко съобщение

is_read флагът се регистрира срещу всеки запис на потребител на съобщение. Стойността на този флаг остава НУЛА, докато съобщението не бъде прочетено от потребителя. То ще бъде актуализирано до ЕДНО веднага щом съобщението бъде прочетено от потребителя. Въз основа на стойността на колоната може да се определи „прочетено %“ за съобщение, което се изпраща до група.

Нека напиша примерен SQL, за да извлека такъв отчет:

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

Механизъм за напомняне

За напомняща функция ще добавя следните колони в таблицата със съобщения:

• Is_reminder – Тази колона показва дали за съобщението е необходимо напомняне.
• Reminder_frequency_id – Тази колона означава честотата на напомнянето. Трябва ли да е на дневна база или на седмична база?
• Next_remind_date – Тази колона съдържа датата, на която трябва да бъде изпратено следващото напомняне. Напомнянето ще бъде изпратено на next_remind_date за потребителите, за които флагът „is_read“ все още е НУЛА. Нова стойност за тази колона ще се изчислява всеки път, когато се изпрати напомняне.
• Expiry_date – Тази колона е крайната дата, когато напомнянията вече няма да се изпращат на потребителите.

Изчисляване на next_remind_date ще бъде както следва – Да предположим, че едно съобщение е изпратено до потребителите на 9/14, понеделник с 10/5 като дата на изтичане за него. Съобщението се изпраща със седмична честота на напомняния. В този случай ще бъдат изпратени напомняния до потребителите на 21.09 и 28.09, за да им отговорят по имейл, и за последен път на 5.10, за да ги подтикнат да отговорят през следващите 24 часа.

Модел на окончателни данни

Заключение

Едно от най-добрите приложения на тази система за съобщения е изпращането на известия до потребители, които са били неактивни в системата от дълго време. Тези известия могат да се изпращат с активиран механизъм за напомняне и известията ще се изпращат до потребителите, докато потребителите отговорят на известието. Потребителите ще бъдат деактивирани на и след датата на изтичане, ако не се получи отговор на известията от тях.

Възнамерявах да създам модел на данни за напълно функционална система за съобщения, която може да се вмести в различни системи за изпращане на съобщения/известия. Чувствайте се свободни да споделяте вашите мнения/приноси/коментари за статията.