MongoDB : where is the limit between “few” and “ma

问题:

I am coming from the relational database world (Rails / PostgreSQL) and transitioning to the NoSQL world (Meteor / MongoDB), so I am learning about denormalization, embedding and true links.

It seems that, in many cases, choosing between various database schemas comes down to the number of documents that will be "related" to each others.

In this video series, the author distinguishes:

• one-to-many relationships from one-to-few relationships
• many-to-many relationships from few-to-few relationships

So, I am wondering: where is the limit between few and many?

I guess there may not be a hard number, but are we in the dozens, the hundreds, the thousands or the millions?

回答1:

It's all relative and is really kind of a dangerous question to make assumptions about when you're designing an architecture. It's worth investing time to make the right choices for your schema and your setup. I would advise a few steps:

1. Do the math. Multiply your relationships out based on what you expect your application to need to do. If you have a few nested arrays or embedded documents, a couple of "one-to-few" can expand out to many documents pretty easily when you start $unwinding them.

2. Write a prototype. Do some basic testing on your expected hardware/environment to see if it can easily handle that load when you do queries for all the data.

3. Based on your testing, create the limitations. This is where you need to draw the line on how many relations you can create per document, for each relationship type, before the system breaks down.

If it were me, I would say one-to-few is less than a dozen, and one-to-many is theoretically unlimited, but practically in the millions. Maybe there should be a middle ground of "one-to-some" to indicate possibly hundreds.

回答2:

Taken from 6 rules of thumb for MongoDB schema design:

1. one-to-few - two until few hundreds
2. one-to-many - couple of hundreds until few thousands
3. one-to-squillions - thousands and up

I totally agree with @womp about the need to choose the right scheme for your use case. The article I posted above has some good guidelines and examples of which schema design to use.