How to make this system design and logic more efficient? (internal messaging system) [closed]
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this questionWe have a basic messaging system, with the following database design
- MESSAGE
- MESSAGE_COMMENT
- MESSAGE_READ
- USER
- MESSAGE_TYPE
When the system sends a board cast message to 1 million users on the system, the message is created along with 1 million records in the MESSAGE_READ is also created for each user receiving the message and this is flagged as unread (ie ReadDate=null).
When 100 thousands user reads the board casted message, those 100 thousand users messages are flagged as being read (ReadDate=currentdate)
When the system sends out an updated board cast message, 1 million reco开发者_如何学Pythonrds in the MESSAGE_READ record is updated and flagged as being unread. (same thing happens when someone replies to the message, everyone elses MESSAGE_Read is updated as unread, until the read it)
How do you make this system more efficient? Is there anyway to avoid creating/updating records to flag them as read/unread records all the time????? (I wouldn't think so??)
Here's a suggestion that come to my mind :
How about creating Message_Read instances on the fly . I mean when you post a message don't create any Message_Read for any of the users. when a user logs in the system checks to see if he has a message that has not been read (no message read exists for it) and alert the user to read them. When a user reads a message a Message_Read record is created for him preventing the system from showing the same alert again. Whenever the status of a message is changed and you want to alert the change you can either delete its Message_Read instances or you can move them to an archive table for keeping the history if necessary , thus there's no Message_Read for that message and user will be notified to read it again.
精彩评论