Mongoose schema/query best practices (MongoDB, node.js)

Question

I'm trying to break down my RDBMS mentality with Mongoose in a node.js app, and could use some guidance as to best practices.

A simple example: Let's say there are two collections, organizations and contacts. It's a one-to-many relationship and they both need to be lonely. In an index method, however, I want to return an array of organization objects, each with an array of member contact objects. (And later I want to return an array of contacts, each with an organization object.)

It seems to me that I'm misunderstanding the best way to accomplish this. Here are the options as I see them thus far:

Embed contacts with their ids in the organization documents. The index query could then be Organization.find({}, function(err, orgs) { orgs[n].contacts[n]...}). Disadvantage: Lots of extra storage necessary, and have to update embedded contact documents any time you change the "master" contact document.
Take advantage of Mongoose's populate/DBRef structure to store "foreign key" ids in both tables. The query can then be: Organization.find({}}.populate('contacts').run(...). Disadvantage: You have to store keys on both sides.
Go the more traditional "foreign key" route, storing just the organization id in a contact document. Query the organization documents and then query all the contacts in the organization query's callback, combining the data into one object to return. Disadvantage: Multiple queries and extra processing overhead (I believe we have to find the orgs and contacts for those orgs independently and then iterate back over each, matching manually on the common _id field, to combine them into a new output object).

I must be missing a better option. Something that allows for the schema of #3 but returns the desired combined object with much less overhead.

NOTE: The async module seems like it could help with this, but is this really the only/best way?

alessioalex · Accepted Answer · 2011-12-19 20:47:38Z

2

This really depends on the queries you are going to make. - Does your site depend more on contacts or on organizations? - Will you often need to display all contacts from an organization? - What details for contacts do you need to display on an organization page?

Etc.

So this really depends on your project's needs. Are you organizations and contacts page constantly being updated? If not than duplicating data doesn't seem such a bad idea, especially if your site is more read heavy.

Bottom line: think on what pages you'll have on the site and what will that pages need to display (thus what queries would need to be made).

answered Dec 19, 2011 at 20:47

alessioalex

63.8k16 gold badges158 silver badges123 bronze badges

Sign up to request clarification or add additional context in comments.

2 Comments

glortho Over a year ago

Thanks for your response. The app depends equally on both contacts and organizations. That is, some users orient much more intensively to orgs, some to contacts. In all cases, all contacts would need to be shown for each organization. Overall, there would be greater read requirements than write, but storage space would eventually be a concern if we were to embed contact data in all org documents. For now, I think it might make most sense to stick with #2 as it mitigates the liabilities of the others. But still seems absurd to store ids on both sides!

alessioalex Over a year ago

It's not that bad, you are just making 2 queries (one for the collection and the other for referenced data). It's the safest solution for you at the moment, then you can change the structure in the future if you want to.

Collectives™ on Stack Overflow

Mongoose schema/query best practices (MongoDB, node.js)

1 Answer 1

2 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

2 Comments

Your Answer

Sign up or log in

Post as a guest

Related