views:

148

answers:

2

Hi,

How would you go about implementing private mail functionality such like Bebo/Facebook and other social networking sites?

You have the option to post public comments on a member's profile, but you can also send a private mail.

I was considering using XML and just storing it as a field in that particular user's record. Does this sound like a bad idea?

Anyone have a better suggestion? I am unsure as to which would be the best solution.

+2  A: 

I may have misunderstood what you want, but how about creating a mail table, with for example

  • Sender
  • Recipient
  • Subject
  • Message
  • Sent
  • Read (bool)

And then just add a row to that table when someone sends a private message to someone.

Svish
Yeah I was considering that option, however, would it not be better performance wise to keep it as a member field? As a global table like this would become huge? Where as if it is a member XML field it will be significantly smaller. However, I have heard that XML isn't always the quickest to parse!
James
I think this seems to be the more popular way than my suggestion. Do you think it would make sense to have 2 separate tables one for Comments and one for Private Mail? Or just have one called Message and have a property called Private which is a boolean.
James
well, you could do it both ways. I think I would probably have them in two separate tables, since comments usually are connected with articles, etc. But if it is just a public mail thing (like a wallpost on facebook), then I would say that your way could work :)
Svish
Also remember that databases are made for handeling lots of data in huge tables (the "real" databases at least).
Svish
Yeah, think thats what I will do, thanks for the info!
James
+1  A: 

I would strongly recommend against storing the messages in a field on your user table. This is very likely to result in performance problems as your application grows. As another answer suggested, I'd add a table specifically to store message data. Below is a pseudocode example of what your tables might look like.

UserTable
{
    ID INT, -- a unique system generated ID
    USER_ID CHAR(20), -- also unique, this is a user provided ID
    FIRST_NAME CHAR(40),
    LAST_NAME CHAR(40),
    BIRTH_DATE DATE 
}

UserEmailTable
{
    ID INT, -- a unique system generated ID
    USER_ID CHAR(20), -- this ties the entry to the record on UserTable
    EMAIL_ADDR CHAR(128), -- user provided email
    PRIORITY INT, -- Specifies the users 0..N-th address
}

MailTable
{
    ID INT, -- a unique system generated ID
    SENDER_ID INT, -- this ties the entry to the record on UserTable
    RECIPIENT_ID INT, -- this ties the entry to the record on UserTable
    CREATE_DATE DATE,  -- record when the message was created by sender
    READ_DATE DATE,  -- record when the message was read by recipient
    PRIVATE BOOL, -- indicates if this is a private message
    MESSAGE BLOB -- the message body
}

Please keep in mind, this is just an example and it may not address the specific concerns of your application.

One final thought: Are you actually planning to store XML in field directly or using some sort of XML<-->SQL mapping tool? If you are storing the XML directly, you may not taking advantage of the abilities of your database. Your concerns about performance are valid, but a well designed & tuned database should easily be able to handle millions of records in a single table.

Hope that helps.

Jason Braucht
Jason, yeah my concern's where if I made a table for mail/comments only, as its global to all members, the tables will get huge. Where as if I made them a field in each member record surely this would result in faster retrieval as you need to retrieve the member information regardless?I would be looking to store the XML directly into the Database as SQL Server 2005 supports XML field and using Guids as the unique id for comments/mail.What are your thoughts?
James
I would rather have a huge table than a table with a gigantic column of text data which must be parsed to be of any use.
Svish
Not to split hairs, but could you please quantify 'huge' and 'gigantic'? In a modern DB, hundreds of millions records is relatively common. Billions or even tens of billions of records are not unheard of. Putting your messages into a field on the user table will almost certainly cause your application to scale poorly. If nothing else, by putting messages in their own table you will have more options if performance becomes an problem.
Jason Braucht