The rise of NoSQL databases has been driven primarily by the desire to store data effectively on large clusters – such as the setups used by Google and Amazon. Relational databases were not designed with clusters in mind, which is why people have cast around for an alternative. Storing aggregates as fundamental units makes a lot of sense for running on a cluster. Aggregates make natural units for distribution strategies such as sharding, since you have a large clump of data that you expect to be accessed together.
An aggregate also makes a lot of sense to an application programmer. If you’re capturing a screenful of information and storing it in a relational database, you have to decompose that information into rows before storing it away. (za AggregateOrientedDatabase).
Z innego źrodła systematyka metod określanych jako NoSQL:
First, we should note that SQL and relational model in general were designed long time ago to interact with the end user. This user-oriented nature had vast implications:
End user is often interested in aggregated reporting information, not in separate data items, and SQL pays a lot of attention to this aspect.
No one can expect human users to explicitly control concurrency, integrity, consistency, or data types validity. That’s why SQL pays a lot of attention to transactional guaranties, schemas, and referential integrity. (za NoSQL Data Modeling Techniques « Highly Scalable Blog).




