One collection - multiple schemas - bad practice?

[Shahar Kedar]

I was wondering if there's any reason to believe that using completely different schemas in the same collection is in some way bad practice. According to every article, doc page or lecture I've read or heard, there's no reason to believe there's something inherently wrong with doing that, but I just wanted to make sure.

[s.molinari]

With Mongo it is certainly possible. The question is though, why would you want to do it? To have totally diverging schemas in a single collection would be a programming nightmare, unless you had some sort of metadata and a key in the documents to link to this metadata to "predetermine" the schema of the documents you are reading from or writing to. 

Scott 

[Stephen Steneker]

On Monday, 15 December 2014 07:28:18 UTC+11, Shahar Kedar wrote:

I was wondering if there's any reason to believe that using completely different schemas in the same collection is in some way bad practice. According to every article, doc page or lecture I've read or heard, there's no reason to believe there's something inherently wrong with doing that, but I just wanted to make sure.

Hi Shahar,

Flexible schema is certainly a benefit for some use cases and there is no requirement for documents in a given collection to have the same fields.

For example, a content management system might have a "content" collection where all documents have some common metadata (author, title, post date, ...) and differing fields by content type (blog, page, poll, ..). In this case the documents in the collection are still related and there will be some benefit in indexes that might apply to different document types within the same collection. This enables use cases like "find me all content created by a given author" in a single query. If you want to index fields that may not be present in all documents (eg. a "tags" field only applicable to blog posts) you should consider using a sparse index (http://docs.mongodb.org/manual/core/index-sparse/).

It generally doesn't make sense to have a collection mixing documents with entirely distinct fields. For example, adding "user" documents (name, email, ...) to the "content" collection described above. As Scott noted, your application typically needs some context to interpret documents so a single collection with mixed types can add overhead in both code & storage. If you have to add an explicit "type" field as a hint for how to interpret the documents you would probably want that field indexed as well; if you used separate collections per type, the collection name already provides that hint.

The Data Model section of the MongoDB manual has some helpful background reading on data model considerations & design: http://docs.mongodb.org/manual/data-modeling/.

Regards,

Stephen