Take the 2-minute tour ×

The Story so far: First, we got one web application and one database for it. Then the product owners decided to make a spinoff of the first application (if the first application was site for clothes, the second site is site dedicated to baby clothes). We made a second database for the second app. And third, forth, n-th after that. I can justify that decision, because the information of the databases did not intersect.

Now: The product owner decided to make a super-application, one application to rule them all. Common story: a user makes a query for some products, and the result must contain aggregated data from different databases (but not all, k from n).

The Question: Is there some common pattern for resolving the common problems which will arise before us?

First approach: Super-database (all database data, copied to one huge database)

  • pros: only one query is needed; it is easier to apply sorting or other filtering
  • cons: how we will differ the origin database of the items; may be some conflicts of IDs; must perform a time consuming and dangerous copying of information; will not be backward compatible with older applications

Second approach: Same databases (no changes)

  • pros: the application will be backward compatible; there will be no dangerous coping
  • cons: one query becomes multiple queries(slower, harder to aggregate)
share|improve this question
You've already listed both options. Now you have to pick one. –  Alister Bulman Oct 1 '12 at 12:12
add comment

1 Answer

Housing this all in multiple databases is fine since MongoDB (of course) has no JOINs there is no real threat having aggregation problems here. I suppose you could get problems in the future if 10gen releases the ability for subselects within aggregation functions etc to allow a sort of pseudo join of types.

There could be one problem with MRs here if you were to do multiple MRs that output to the same collection but then MRs can output to different DBs now (has been available for a while now) so that's fine.

Also with mulitple databases (in 2.2) the lock will be on your side since the locking mechanics in 2.2 are DB level.

In my personal opinion, taking the problems of copying and conflicting IDs into account, I would stick with what you have got and just make an abstraction layer to make it look like it is coming from one database.

Of course if you feel as though it would be a real logic problem to house it in different databases and you will easily mix up the data then you might have no choice.

share|improve this answer
add comment

Your Answer


