Categories
- BLOG -

NoSQL vs SQL – A Mediocre Walkthrough

For IT experts things are getting heated up as they must embrace the possibility of adopting NoSQL.

All that I knew of it until last summer was that Google and Facebook back it. But what is NoSQL? How does it work? Is it stable? Its real-life applications, please?

Last year while investigating data storage formats for a product I’ve been working on, I decided to find answers to these questions for myself. Let me share what I found:

To understand NoSQL, we must first understand what is negates by its very name: SQL. NoSQL is essentially not SQL.

SQL, abbreviation for standard query language, is a programming language for interacting with relational databases. Relational databases are a form of storage centered around tables. All data being stored in a relational database has to go into a table consisteing of fixed fields/columns each having set properties.

But why ‘relational’? You see, when all you’ve got are tables; you need relations between tables to allow for complex data structures to be erected. An employee database can’t simply store all of the info about a user in one table with fields like [name, address, email, phone]; What if the employee changes their address? The adress data should have a hostorical component; so in a relational database, you would create one table for the employee where their basic data would be stored, and another for keeping track of their addresses with a column for ‘moved in’ and another for ‘moved out’. So that if a certain employee’s address from 2009 was required, you could retrieve it from the archives.

Therefore, tables tend to have relations between each other with foreign keys, or application layer constraints so that any degree of complexity in data structures can be achieved with relevant tables and table relations.

Makes sense? Relational databases are a topic of their own. If you need more insight, I suggest using your best friend, which is Google, to find out more.

SQL is also often used with the term structured data since data generally has to be quite well defined in its structure when being stored into a relational database.

NoSQL is therefore a query language that interacts with database management systems that are not relational. The ones I researched typically use a popular data definition format called JSON. Ever heard of XML? JSON is the more human friendly, distant cousin of XML. It allows you to define trees of key-value pairs with never-ending branches of data.

Do you see where this is going?

SQL is a related-table approach to data definition.

NoSQL is a no-table approach to said definition.

What does that mean? I believe some bits of computational theory and computational constraints come into play here. When you’re storing data in tables, and linking them by fields; you create a spectrum of strengths and weaknesses for a computer to traverse through that data.

When you drop the tables (pun intended?) and just have free flowing data in a format like JSON, you create a different spectrum of strengths and weaknesses for the computer to traverse through that data.

Makes sense? Let me try to explain this one a bit more…

In SQL, when I query an employee with the name “John Doe” and an address “2232 York Blvd, Mississauga ON” in the year 2009; the SQL server has to first look through the employee table for all people with the said name; collect them in memory, then traverse through them and their address records for the said period, to filter the right results;

Where as, in NoSQL the DB server has to traverse the large JSON document to pick out the right employee records with the said name, and then pick out the ones that have the address record as a child that matches the said period.

In the above two different scenarios two different styles of slicing through large sloths of data are presented; and that gives rise to questions of how the computer uses its memory and CPU to come to the final outcome.

So when you set out on finding out which type of database you should use for your next information system project; look for commentary by experts on how each of these database types performs in handling the type of data operations you are going to be exacting in your application, most.

If I speak any more; we might need to write a book. However, you are welcome to speak to us about any questions you may have; we would love to provide a researched opinion on database options for your data needs!

P.S. Oh, did I mention that SQL databases are now moving into NoSQL storage formats as well…?

Look out for part two…


By: Mustafa Ghayyur
July 23rd, 2018