Take the 2-minute tour ×

I'm creating an online chat.

Context (if needed):

So far I was using PHP/MySQL and AJAX to do the job but this is not a healthy solution as I'm stuck with a "pull" type application with concerns about scalability. I read about the "push" method alternatives and it seems that my choices are limited and exclude PHP. Websockets could be a very interesting option if it was integrated in every browser but that's not the case (and it seems that for most of those implementing it, it is disabled by default). Long polling would also be a candidate but it involves other issues like the number of concurrent open connections that may kill your web app too.

This is why, against my will, I think that my only viable option is to use server-side javascript (node.js + now.js would be my choice then).

This said, I may need to rethink the use of a database too. I need to keep stored data of each users and link these users to their submitted messages. In case of a chat engine driven by a push system, would MySQL still be a valuable choice then? I read about NoSQL data management and it seems that MongoDB would be a good addition to node.js.

My two questions:

  1. Is there a reason I'm better off moving to a NoSQL system (which I need to learn from scratch) instead of MySQL (which I know already) in case of a real time web app?

  2. Let's say that in MySQL:

    • I have a table called user (user_id_p, username)
    • I have a table called messages (message_id, message, user_id_f)
    • I want to make a single query to get all the messages associated with the username "omgtheykilledkenny".

    Simple enough but how can I achieve that with MongoDB and its collections philosophy?

Thank you for your help.

share|improve this question
#1: Yes - speed and scale are two reasons #2: Its pretty easy to do what you're trying to do using mongo. Have you RTFM'ed and do you have a specific question, or are you asking us to teach you? –  ControlAltDel Apr 23 '12 at 18:22
Please believe me, I RTFM but I just don't get it. I just can't find how to make relationships between collections. It may be obvious for experienced developers but it doesn't make sense to me.Simple queries within a same collection is ok but combining data between two collections to get a response is out of my understanding. Didn't find anything related to that so far. Besides that I believe my questions are very specific. –  Baylock Apr 23 '12 at 18:24
add comment

2 Answers

up vote 0 down vote accepted
  1. Working with node.js/MongoDB is cool because Mongo's document structure is already JSONish, so you don't have to convert your queries to JSON. If you already know JavaScript, you have a headstart learning MongoDB. Mongo does scale for writes and reads pretty easily, the speed is pretty awesome, although I've seen some MySQL benchmarks on a single system that compare well to Mongo--it really shines when you start needing multiple boxes.

  2. Assuming you have a separate messages collection, and you already know the id of the user you could just do: db.messages.find({user_id:ObjectId(...)});

Update: If you don't know the user id, then you need to do two queries, yes (unless you use an embedded array as recommended in the other answer--I would advise against that for this sort of use case, though, because you'll end up querying the entire document/list of messages even to display just a subset). Depending on your use case, obviously, if you have the username, you could also keep the user id handy, for situations like this. If it's client input giving the username that wouldn't work.

Update2: If you have unique usernames, you could make the username the _id for the users collection to avoid this issue. Most people would probably advise against this, and it has some definite drawbacks, such as making it harder to change a username.

share|improve this answer
Thank you Wes Freeman. My first answer is completely answered. For the second one, I'm not sure. In your example (which I RTFM'ed clearly) it assumes that It will give me the messages from the user_id I provided but it will not give me the messages of a specific username (which is available in the other collection called "users"). This is easy with two queries (I query the id of this username and then I query the messages of the user id I retrieved) but with one and only query, how would I do that? That's my point. –  Baylock Apr 23 '12 at 18:33
Added some updates. –  Wes Freeman Apr 23 '12 at 19:23
Thanks. I would like to set both your answers as valuable but it seems that only 1 is allowed by question. Regarding the matter I can't keep any user_id in session as I may need the id of any user (or none). And for the username as an id, it will not answer my issue as the username here is an example. I need it but I also need to attach to the message, the user gender, birthdate, avatar, etc. These are user related, not message related. The only common point between users data and messages is the user_id as there's more user data I may have to retrieve from a message than the user name. –  Baylock Apr 23 '12 at 19:41
Yeah, unfortunately you'll need to do two separate queries to get all of the user attributes and all of the user messages, or embed your list of messages within the user (which will have trouble scaling to many messages). –  Wes Freeman Apr 23 '12 at 19:42
By the way, doing two queries isn't the end of the world, unless you're a bank doing transactions, or something sensitive like that. –  Wes Freeman Apr 23 '12 at 19:46
show 2 more comments

You can't perform joins in MongoDB, so you can't achieve your second requirement. The Mongo way so do this would be either to nest messages within the user collection:

{ username: 'abc', messages: [...]}

Or use refId's, which is a kind of half-way house between joins and nested documents:


In terms of switching from MySQL to Mongo, you don't necessarily need to ditch MySQL entirely. There are use cases where one is more appropriate than the other. You could use both for different parts of the system if it's appropriate to do so. Personally, I've used MySQL for a lot of things in the past, and I'm using MongoDB for a big project at the moment. I found the move very easy to make, because it's so easy to use the MongoDB driver, and the MongoDB site is very good for documentation on the whole.

You can convert to and from JSON with json_encode and json_decode from the front end, and you query and insert/update with arrays with MongoDB's PHP driver, so it's arguably more intuitive and easier to use than MySQL. It's just a question of getting used to it.

share|improve this answer
Thank you Mick Sear, it's very interesting. For the 1st question, I read a lot about the pro's and con's for each system but I just don't know which one applies best to my own use cases. The traditional "MongoDB because speed and scale" seems like too dogmatic to me. I don't mind learning MongoDB but only if it makes sense. Regarding my 2nd question, it seems that I should learn more about dbrefs. Reading TFM may show you the query syntax, it doesn't help you apply a theoretical concept. I still think the MySQL way and try to adjust myself to something different. Not that easy. –  Baylock Apr 23 '12 at 19:31
I would like to accept your answer but I only can except one. Yours is theoretical and very instructive. The other one is more "straight to the point". Thank you, both of you. –  Baylock Apr 23 '12 at 19:43
@Baylock, you can't accept the answer, but you can always vote it up :) Pleased my answer helped you anyway! –  Mick Sear May 20 '13 at 20:40
add comment

Your Answer


