Mongoose Mtg Sets

Elvenware Logo



Mongoose and MTG sets takes a slightly different tack than the two other applications we have seen in this serious. The other two apps can be described like this:

The goal of this app is to:

Again, just to make clear what is happening:


The code:

Each call is made in the callback to the previous call

For instance, here is how the code to empty the collection, once it is finished, calls the code to insertData:

MagicSet.remove({}, function(err) {
    if (err) throw(err);

Here is how the code to insert a set, when it has finished inserting all the sets, calls Search: {
    console.log('saved: ',;
    if (totalSetsSaved === setNames.length) {

Turn It In

Run the ParseSets.js file. Take the following screenshots:


NOSQL databases are not for everyone. However, if one were to make an argument for NOSQL databases that did not involve big data and vast numbers of irregularly shaped documents, then the kind of data found in MTG would seem to be a good example of a task better suited to NOSQL database than to a SQL database. I find it easier to think of cards as sub-documents rather than as a table bound to another table through a foreign key. It's not that relational databases can't handle this kind of data, but only that there is an awful lot of machinery required to abstractly handle concepts that make obvious, concrete sense when placed in a NOSQL database.

NOSQL databases can handle rapid transactional requests with reasonable accuracy. However, it is arguable that in some cases the years of experience behind databases like MySQL or PostgreSql make them better choices for some databases that have to handle thousands of users simultaneously pounding on a database with multiple CRUD operations. The MTG, database, is not that kind of database. We need to insert the data once, and after that we simply query it. Why introduce a lot of machinery designed to ensure save transactions when they are not going to be any transactions?

SQL databases are highly optimized. It is hard to believe, however, that any degree of optimization is going to make a SQL database that must perform a join between two tables called sets and cards faster than a NOSQL database that simply retrieves a single document from a btree file. Again, why introduce all the overhead and complexity of a SQL database in order to perform a relatively simple task like retrieve one of 178 documents from single file?

SQL databases are built around mathematical principles. They are faster, elegant, cleanly designed. But not everyone thinks in purely mathematical terms. For many people, it will always be easier to think about documents than about tables, sets and keys. It is not that one is better than the other, it is that they serve different tasks.