Question

http://martinfowler.com/articles/dblogic.html

Using the terminology of the above article, the Transaction Script pattern of coding is clearly an antipattern when dealing with SQL databases.

Is the same true of NoSQL databases (like MongoDB) also? Assume that the columns – which the nosql query will be using -are all appropriately indexed.

The reason I ask this question is: Query execution in MongoDB returns a cursor, which can be iterated upon. What I don’t know is, whether or not there is a performance penalty associated with it.

Answer 1

The article describes a “Transaction Script” as

[a] procedure reads in all the data it might need and then does the selection and manipulation in-memory to figure out which [database entries] are needed.

Every NoSQL database is different, so you can not generalize anything for “NoSQL”. But in almost every database system it’s a good idea to do as much on the database as possible.

1. As long as you are using the query syntax of your database, it can at least in theory use indices to speed up certain operations, but as soon as the result set is returned, the index information is lost, which makes these operations more expensive.
2. When you get a huge result set from the database and then filter it on the application layer, you have to pass all that data over the network. Depending on how well your network infrastructure works, this can become a performance bottleneck (assuming that your database is on a different physical server – which it usually should be in a production environment). Transfering huge datasets also screws with any buffering systems of the database or your database driver.

When you are asking about MongoDB specifically: MongoDB databases aren’t designed to be as “smart” as SQL databases. The design assumes that many problems which SQL databases solve themselves, are solved on the application layer instead (constraints, cascading deletes, joins, transactions…). The query syntax also isn’t as powerful as all the features which accumulated in 40 years of SQL development. That means that you often don’t get around doing filtering on the application layer. But when a problem can be solved with the query syntax, you should generally try to do so.