Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>First, you have to know if your notifications are broad casted to all your uses or can be user specific. In case of Facebook, I would say it's the second option. </p> <p>My first recommendation, is to find an open-source project (or may be even 2) that implement this feature and look at their code.</p> <p>My second recommendation, is to write down all the requirements for this feature, as often, a small restriction can induce a modification on the table structure or even an addition of a new table (For example, can a notification be sent to multiple users at once? can a user send a notification to another user?...).</p> <p>Here's the way I would go, using 2 tables, one for the message and one for the NtoN relation with users: <strong>Table Notification</strong></p> <pre><code>ID // auto increment ID sender_id // Can be a subsystem or another user. To be defined / optional. Does not have to be a foreign key. title // Title of the notification body // The text message type // warning, message, error or any notification class you can think of ... // you can add other options, like priority, attachment... </code></pre> <p><strong>Table Notification_User</strong></p> <pre><code>notification_id // Foreign Key for the notification receiver_id // Foreign Key for the user is_read // is the notification read is_deleted // is the notification deleted, this implements a Trash bin like feature created_at // time at which the notification was sent read_at // time at which the notification was read deleted_at // Time at which the notification was deleted </code></pre>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload