MongoDB Applied Design Patterns Quotes

“MongoDB is sometimes referred to as a “schemaless” database, meaning that it does not enforce a particular structure on documents in a collection. It is perfectly legal (though of questionable utility) to store every object in your application in the same collection, regardless of its structure. In”
― Rick Copeland, MongoDB Applied Design Patterns

“By “punting” on these problems and not supporting joins or multidocument transactions at all, MongoDB has been able to implement an automatic sharding solution with much better scaling and performance characteristics than you’d normally be stuck with if you had to take relational joins and transactions into account.”
― Rick Copeland, MongoDB Applied Design Patterns

“MongoDB was designed from the ground up to be easy to scale to multiple distributed servers. Two of the biggest problems in distributed database design are distributed join operations and distributed transactions.”
― Rick Copeland, MongoDB Applied Design Patterns

“One final factor that weighs in favor of using document references is the case of many-to-many or M:N relationships.”
― Rick Copeland, MongoDB Applied Design Patterns

“The fewer documents in RAM, the more likely the server is to page fault to retrieve documents, and ultimately page faults lead to random disk I/O.”
― Rick Copeland, MongoDB Applied Design Patterns

“larger”
― Rick Copeland, MongoDB Applied Design Patterns

“In a RDBMS, since all the column names and types are defined at the table level, this information does not need to be replicated in each row. MongoDB, by contrast, doesn’t know, at the collection level, what fields are present in each document, nor does it know their types, so this information must be stored on a per-document basis.”
― Rick Copeland, MongoDB Applied Design Patterns

“The constraints of a toolset help to define patterns for solving problems. In the case of MongoDB, one of those constraints is the lack of atomic multidocument update operations. The patterns we use in MongoDB to mitigate the lack of atomic multidocument update operations include document embedding and complex updates for basic operations, with optimistic update with compensation available for when we really need a two-phase commit protocol. When designing your application to use MongoDB, more than in relational databases, you must keep in mind which updates you need to be atomic and design your schema appropriately.”
― Rick Copeland, MongoDB Applied Design Patterns