If you are used to the way that SQL databases work, then you are also used to the implementation of a counter cache. In Rails it is a trivial implementation. Essentially, it will internally maintain a cache of the count of associated objects in a relation, this results in more data management but it avoids an extra query every time you need the count of associated rows.
In MongoDB, certain types of associations will get this functionality out of the box. With a HABTM and a many to many relationship, the counts will be stored by virtue of the type of associations. This is because there are no joins in Mongo, so the references to a document must be stored directly on that document. Therefore, you end up being able to do something like
In Mongo, there are no joins, only more queries. This can be kind of annoying if you are used to doing more work directly on the database. This means that if you want to join two tables, you need at least two seperate queries. It also means that you need to think more seriously about where certain data needs to go. Should it be in it's own document or embedded in another? The upside, is that aggregations within a collection are extremely powerful.
N + 1 Fun
A quick note, if you are using something like ActiveRecord you can still easily avoid the N + 1 query problem. A call to
include works more or less the same way, but of course it will be done with 2 queries instead of a join.
People tend to think that the fact that MongoDB is schemaless means that you can just add new attributes or change attributes without worrying too much about the ramifications. This will create some of the saddest querytime that you have every had. It's true that you don't have to migrate columns as with a traditional SQL database, but if you change an attribute name and don't migrate the data, be prepared to have your queries handle the old data and the new data. There is no free lunch. :(