I've just read the following posts on the same topic:
Facebook like notifications tracking (DB Design) and Database design to store notifications to users
Some solutions were offered but not exactly what I need and how it should be for a Facebook-like notification system.
In a notification, we often have some links pointing to the user who took some action, link to a post or video he commented on, link to anything, and ofter we have several links in a single notification.
notification
-----------------
id (pk)
userid
notification_type
notification_text
timestamp
last_read
With this table structure we can show all notifications for a single user and it is pretty solid solution. But in this case, we can only display a plain text notification. We cannot simply link to a user or a wall post.
I'm trying to come up with a solution to this problem. One is to store BB Codes in notification_text property, but then you need to write BB code parser both for web and mobile applications. Another would be creating another table which derives from this notification table with ID's for entities we need. An example:
PostCommentNotification : Notification
----------------------------------------
id
userId (user who commented on a wall post)
postId (post where comment was made)
Now we can write a template for displaying the notification (we don't need the text property in notifications table anymore now) and then handle displaying it. I'm not satisfied with this solution either since the number of tables deriving from notification table could be big (for each notification type).
I'm looking for ideas! :)
Unfortunately not a lot of answers here. I had the same problem and didn't find any good solution. Inheritance in databases are always tricky and get complex too quickly. So I ended up with a simple solution: storing a key value array of resources wrapped in JSON in a "data" column.
Something like this:
notification
-----------------
id (pk)
userid
notification_type
notification_data
timestamp
last_read
For example, for a comment notification, you'll store
[{"author_id": "1234", "comment_id":"1234"}]
Then you use the notification_type to format correctly your data on client-side.
Can't see any drawbacks as we only need resources id on client to create urls or intents, having atomic fields for indexes is useless.
Hope this helps.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With