Introduction to MongoDB : A NoSQL database

For some time I have been studying the MongoDB . Within the class of NoSQL DBMSs this was the one with which I ended up creating greater sympathy for its simplicity and documentation ( although many people talk about Apache Cassandra , its documentation is still horrible) .

MongoDB is a database -oriented documents. So if you , like me ( and 99 % of developers ) come from an environment dominated by the relational model , at first see this DBMS as an alien – which is incredibly exciting and scary. My goal in this post is not to teach how to use MongoDB ( will be close to the subject) , but explain the main differences between this and the comfortable relational model .




This scary ( and wonderful) “new world”

For accustomed to the relational model , MongoDB will prove daunting at first contact because most of the concepts that provided us a certain sense of security basically ” disappear ” . This is required coping with fear : as I will show in this post , there are risks , but the gains outweigh the .

I do not think non-relational model can be applied to all cases , but it is always important to know more than one paradigm so that we can at least expand our horizons when we encounter situations that are beyond our comfort zone ( and MongoDB can be quite uncomfortable at this moment ) .

There are no records , but documents

Something always bothered me in the relational model : with him try to represent the real world (which is n- dimensional ) using a two-dimensional approach. All I represent is in my tables has only two dimensions: rows and columns. It is true that we can represent how many dimensions we want in the relational model from relationships , but there is always that feeling of being ” pushing it ” .

Moreover , however well made it is the process of analysis , there is always the possibility of later another attribute be encontardo . The world is a complex environment : believe to represent you also need a complex terminology .

In MongoDB , the equivalent of records are the documents that use JSON syntax. The best way to have a feeling of what I mean is to see the animal. Therefore , note the code below :

Kico = {
name: ” Henry Lobo Weissmann “
nickname: ” Kico (or would this name? ) “
city : ” Belo Horizonte “
}
I created a document called kico which has three attributes: name, surname and town. Note that at no time set the maximum size of each attribute validation rules or any kind of restriction. Then if you want to store it in a database , it would be enough to run the code below:
1

db.kicodb.save ( Kico )

In this case , I would be storing the document in Kico kicodb database. Now , note the code below :
nickname = { name: ” Angelica Maria Alvares da Silva and Silva “
nickname: ” Nanna “
spoused : ” Kico “
city : { name: ” Belo Horizonte ” , state : { name: ” Minas Gerais ” , parents : ” India “} } ,
Clothing: [ { name: ” Fraud ,” race ” Pinscher ?”}, { name: ” Joe ,” race ” Schnauzer “}] }

db.kicodb.save ( Nanna )

Note that a record with completely different structure was included in the database . Until the city attribute is different. While the record ” Kico ” I have only one string in Nanna object I have another document. Another interesting point : notice I even have a collection associated with Nanna object.

And everything is still saved in the same database without any problems. In fact, I could store up the record down smoothly

Oddball = { number : 34, poemaFavorito ” Batatinha “}

As can be seen , there is no strict validation rules : any document can be stored in the database . Clear: in practice only similar objects are stored in the database , but it is nice to know that if one day appear a new attribute , we can just include it in the document where it is necessary, unlike the relational model , where a pillar applies to all records .

Disadvantage: the developer needs to be smart so that your databases do not see a ” samba Zany criolo ”

Advantages:

Finally you got rid of a two-dimensional approach and may represent real-world objects as they really are : complex and unique .
If in the future arise a case in which new features appear , you can apply them only where it is necessary, and not in all cases , as in the relational model , where normally creates a new “column ” in the related table

Maximum data redundancy

In the relational model, we are all the time encouraged to reduce the maximum data redundancy . In fact , relationships are just for this. And it’s a model that works undeniably well . In the MongoDB the situation is reversed : there is no relationship , and duplication of data, so I observed is even encouraged .

Take a look at the code below:

person1 = { name: ” online-seva ” , city: { name: ” hyderabad ” , state : ” MG “} }
person2 = { name: ” online-seva ” , city: { name: ” hyderabad ” , state : ” MG “} }
pessoa3 = { name: ” jose ” , city: ” Hyderabad “}
person4 = { name: ” Complexed ” city : { name: ” Hyderabad” , state : { name: ” Rio de Janeiro” , parents : { name: ” India “} } }

Remember that here there is no tables: there are collections of documents. In each document it stores the data the way I want. I could create a collection containing only cities and then create a relationship between two or more distinct collections, it is true (flees the subject of this post), but this would go against the basic idea behind the document-oriented model.

The basic idea here is that a document must be self-contained, ie isolated should already contain all the information you need. Why this? Simple: because you so instead of making a query with multiple joins as is the case of the relational model performs a single query that returns you have the entire document. Result: more performance.

Disadvantage: If you want to change all records related to a semantic unit, you need to treat them one by one

Advantage: higher performance. A single query now returns you everything you need to know about the document. This is one of the reasons which have been adopted in projects that require high performance.

In conclusion

These are the two main differences (which are only advantages according to the case) I saw in MongoDB (from documenots-based model in reality) with respect to the relational model. It is applied to all cases? Of course not.

The important thing in my view is to leave the comfort zone of the relational model: this, as I mentioned, broadens our horizons, makes us see other possibilities in addition to tables to store our data. I get scared when top with developers who can only develop something that involves tables, columns and records. In fact, the great advantage I see in this “fashion” of NoSQL models is precisely this: the exhibition of “new” paradigm to a world dominated by the relational model, which only consider bad when taken as the only viable alternative for most people.

This post is key so I can go to the next, in which I will explain how to use MongoDB and, more importantly, how to apply it with Groovy and Java. Big hug!




LEAVE A REPLY

Please enter your comment!
Please enter your name here