Hacker News Reader

Comment by sv123 | Hacker News Reader

I like the idea of Mongo and have read about it but my relational mind can not be unwrapped. Maybe I am trying to complicate things too much. In that example if you have multiple people attending one event and you want to update the event name, do you have to go through all the people and all their events and update each one? Seems like that would be a lot of work, unless there is a way to query for that type of thing? And if there is a query, is it efficient? Seems like behind the scenes mongo would just be iterating through the users, but I'm sure there is more to it than that.

View on HN

Use 2 collections (tables).

Users

- id

- events_attended (array of event ids)

Events

- id

- users_attended (array of user ids)

If you want to get events a user attended, do a query like:

1) get the user.events_attended array

2) events.find({_id:{$in: [user.events_attended] }})

3) now you have a nice json object of all events the user has been to

If you want to get all users that went to an event:

1) get the event.users_attended array

2) users.find({_id:{$in: [event.users_attended] }});

3) now you have a nice json object of all users who attended and event

i.e. do it like you would in a relational database.

In real life you would have a users collection and an events collection, and the events field of users would be an array of event ids.

My first response was "not necessarily," but I'm gonna ratchet it up a notch to a flat out "you're wrong."

Storing event_ids as an array in the events field defeats the whole purpose of organizing your data into rich documents.

In real life, you very well could build something where the events info was built straight into the user record.

seems like a relational database to me...only without the ability to join?

Sort of. MongoDB tried to keep a lot of the trimmings of a relational database, but remain scalable. Joins are handy, but don't scale well.

Actually it would probably be best to reverse the relation and put user_id's in the event objects. Then you can do queries like this:

    db.events.find({hosted_by: MY_ID})
    db.events.find({invited: MY_ID}) // invited is an array of users

Ahh I was not clear. sad trombone

In this case, the events in the user document are events that the user is HOSTING.

There would be another object in our data model to represent the people that got invites to the event. These 'recipients' could be another collection or a list embedded inside each event object.

So then similarly if I wanted to see all the events that I was invited to would I have to loop through all users, all their events, and all of their invitees to see if I was one?

You're going to a depth that is testing the limits of my example :) You wouldn't have to do that. You can have deep indexes, and query on those attributes. So if events had invites embedded, and invites all had email addresses for their recipients:

db.users.find({'events.invites.email': 'sv123@gmail.com'})

and that would return all the users that had invited you to an event.

Now, like I said you're testing my example. When these kinds of requirements are taken into account, you'd probably want to have a separate collection for events. Then you could do:

db.events.find({'invites.email': 'sv123@gmail.com'})

Reply on news.ycombinator.com