NoSQL vs SQL is like saying Warehouse vs Hotel
I am writing this article while trying to find an analogy for NoSQL (non-relational) and SQL (relational) databases to facilitate a discussion with a client to explain why particular data storage fits better for a specific requirement. I want to share this, as it might be useful for others as well so that people will stop saying things like “SQL db. is more secure than a NoSQL”, “ NoSQL is more expensive than a SQL”, “SQL is much better than NoSQL or vice-versa”, “You don’t need a NoSQL because you are not developing a big-data application” etc.
Both kinds of storages have their peculiarities and the difference is in the way the two are designed and built, the type of information stored, and how it is stored. Therefore, I came up with this analogy:
A NoSQL is a Warehouse as a SQL is a Hotel
(Note: I am positive that this analogy was previously created, however, a thorough Google search failed to locate any such similar quotes. My apologies if someone came up with this similar analogy and I failed to cite them:-) )
The point that I want to make is that you cannot blandly compare a Warehouse with a Hotel; both of them are capable of containing “things” but probably different ones with different constraints and different needs. We cannot say that a hotel is better than a warehouse and vice-versa; it all depends on the purpose intended.
Examples:
If I have persons to be hosted somewhere, I could probably host them in a warehouse, but I would recommend a hotel for the following reasons:
1) A hotel provides specific rooms with a well-defined number of beds so that persons are accommodated based on the type of relationships between the persons in the group. (Things like rigid and structured data in SQL).
2) A hotel provides a set of mandatory services/equipment for each room, which are needed for each host, things like heating/air conditioners, showers, toilets, etc. Each of these services/equipment has its own complexity and need to be associated to different rooms. (Things like normalization and relations in SQL).
3) A hotel provides a 24-hour check-in and checkout mechanism so that persons can arrive and depart at any time with certainty. Therefore, the check-in process should be just as reliable as the checkout process. (Things like ACID transactions in SQL).
If you need to store generic items, I could probably store these in a hotel room but I would prefer to store them in a warehouse for the following reasons:
1) The warehouse rooms/areas have a simple, flexible structure and space, which allows for the storage of items that might change the size and shape often over time. (Things like free-schema data structure in NoSQL).
2) The warehouse can provide different and flexible policies in terms of check-in (write) and checkout (read). For example, I can store items only between certain hours (8 am to 8 pm) but withdraw items at any time. (Things like optimized read/write and eventual consistency in NoSQL).
3) The warehouse allows an easier way to scale the allocated areas in instances of growth of items over time. (Things like elastic scale and partitions in NoSQL).
These are just a few examples, but I am sure your imagination can come up with many more examples, which can depict the differences between the use of a warehouse versus a hotel and vice-versa. Based on the above examples, you can imagine the warehouse and hotel being designed in different ways, so that they satisfy the different users’ needs. This is the same for NoSQL and SQL data storage.
SQL
A relational database is designed to store rigid and structured data. It consists of multiple tables with rows and columns. Each table has columns, and every row in a table has the same set of columns.
To have an efficient relational database, the data should be structured and organized. A well-designed schema minimizes data redundancies and keeps them synchronized. Indeed, a SQL database is very useful when strong consistency guarantees are important, where all changes are atomic and transactions always leave the data in a consistent state. The ACID (Atomic, Consistent, Isolated, Durable) feature is extremely important for business requirements that have sensitive data like financial transactions and personal information. However, this feature is not designed to scale out by distributing storage and processing across machines. Also, the normalization process can lead to inefficiencies, because of the need to disassemble logical entities into rows in separate tables, and then reassemble the data when running queries.
In Azure world, Azure SQL server is the most common relational database.
NoSQL
A NoSQL database is designed to store unstructured data. Instead of tables, the NoSQL database can be key-values, documents, and is graphs oriented. The common factor of the NoSQL database is the flexibility it provides when dealing with data.
The document-oriented is the most common NoSQL database, and this simply means that non-structured data can be stored in a single document, which can be easily found.
Typically, a document contains the entire data for an entity, which has a structure specific for the application. For example, an entity should contain the details of a customer, an asset, or a combination of both. Usually, a single document may contain information that would be spread across several relational tables in a relational database. For example, if as a requirement we have to retrieve customer details every time we query a property, it is more efficient to have all the data in one document, instead of having to query across multiple SQL tables.
A document store does not require that all documents should have the same structure. This free-schema approach provides a great deal of flexibility; it facilitates rapid software development, applications can store different data in documents as business requirements change.
In addition, a NoSQL store can be extremely scalable, as the data store can easily distribute data across multiple nodes on separate machines.
In Azure world, Cosmos DB is the offered non-relational database.
Conclusion
The fundamental difference between the two technologies is that a relational database has a pre-defined and well-defined structure, while a non-relational database is unstructured and can store data of any form. Both have their advantages and disadvantages but none is better than the other. The selection chosen depends on the requirements, for example, the type of data that is to be processed.
In modern application, especially with Microservice Architecture, a Polyglot Persistence Approach is utilized where it is common to store different types of data in different data stores, each focused toward a specific workload or usage pattern.
References:
https://datawarehouseinfo.com/sql-vs-nosql-which-database-approach-is-better/
