Messaging system design pattern

Question

Hi,
I'm working on a messaging system build into my application.
As a system administrator, I create messages for all the users. When a user logs in, I want unread messages to be displayed so I have to keep track of wich user read or didn't read newly created messages.
The simplest way would be to keep track of which message was read by which user but that would increment my database until the end of time (or at least until 2012 )
I would think that it's better to keep track of which user didn't read which message but then things would get complicated when a message is deleted.
Also, should I store the user with the message or should I store the messages with the user?
Does anyone have experience on this? Any suggestions?
It's not a technical problem but an architectural one.
Thanks,
Dany

Answer 1

ok, suppose I have a READ_STATUS field, how would you store it then?? You have to keep track of ALL your users and that for all your messages. Suppose you have 25000 users? What I do now is store a comma delimited string for all unread users. So, in a new message, I create a string with the id's of all current users, like 1,2,3,4....24999,25000. In Flex, I convert this string to an array, which makes it easy to delete the current user's id and then write this string back to the db. Something inside me tells me that there have to be more effecient ways to do this...?
BTW, I don't use ORM, that's just the problem. If I have a person with several addresses, I keep a seperate table for the addresses and retreive those before sending a single person value object back to Flex. As it's not likely that a person would have more than 100 addresses (unless he is a criminal or Michael Jackson) this method is fine, but with storing thousands of user id's per message, well... suggestions?
Dany