SQL is an abbreviation for “structured query language”, SQL is the standard query language used for the relational databases, SQL is characterized by having a structured schema, structured schema means that there is an explicit schema used to describe how data is going to be organized, relational database organizes data into tables which also goes by the name “relation”, relational databases are organized into rows and columns, columns represent the attribute for a certain table, a row represents the actual value of this attribute(column), these structures ensure data consistency where an explicit schema is identified and used, this schema is known as schema on-write, we will dive deeply into SQL later on in this article.
We can conclude from its name that NoSQL does not work in the same manner as SQL does, it means NoSQL, There is an exciting story behind its naming, After the official conference where the document model was introduced, developers on Twitter kept tweeting on the announcement with the hashtag #noSQL, the hashtag went so viral, The creators decided to name the document model NoSQL.
NoSQL is organized into a collection of documents, a document in NoSQL is equivalent to a row in SQL and a collection in NoSQL is equivalent to a table in SQL but with more flexibility.
Schema on-write and on-read
Schema on-write is defined as the need to define explicitly a schema for the data before writing data which can be described as structured schema, structured schema? sounds familiar right! SQL follows schema on-write rules, as we have to define explicitly the attributes and their type before writing data, for example, the type can be an int before writing into a SQL database, failing to do so will cause type mismatch error or different errors, Schema write is a costly operation when dealing with huge chunks of data, we will look how schema write can be a costly operation after defining schema read.
In schema-on-read, you do not have to define a schema for data when inserting data points into your database, NoSQL follows the schema on-read style, where different documents belonging to the same collection can have different attributes, a schema on-read is not equivalent to a schemaless schema, schema on-read has a schema different from that of schema on-write, schema-on-read structures or organize data points into a schema(JSON or XML) when reading them which makes the writing operation more agile and flexible.
We can not Argue that one schema is better than another schema, both schemas have their use-cases, it depends mainly on the data itself whether it is structured or not, during the ETL(extract, transform, load) process, ETL means transferring data from one source to another(destination), let say we are trying to transfer loads of unstructured data from NoSQL database to a SQL database, imagine the overhead we have to do to pattern match tables and rows using regular expressions and identify attributes and their correct data type, all these operations will happen in the extraction phase, it can be observed that schema on-write is not a good choice in this case but if the data is already structured, schema on-write is a better choice.
Choosing schema depends on the problem you are trying to solve and the structure of data and other factors.
SQL use cases
SQL is one of the most popular data models which have an explicit schema that shows the relationship between different tables, SQL is a great solution for applications that are user-oriented and use a moderate number of join operations, SQL explicit schema is why it is popular and widely known because it ensures compatibility and can establish the ACID properties unlike NoSQL, SQL which follows the relational data model is one of the best data models out-there, what made SQL earned its reputation, the fact that SQL came after many failures like network model by CODASYL, computer scientist and programming were trying to establish efficient and strong data models where they can access the data easily and intuitively, SQL achieved this for them.
NoSQL use cases
NoSQL is characterized by having more flexibility than SQL which means it is good for applications with nature of dynamic data that have more than form, most NoSQL databases do not support joins operations which is a very important function for a lot of applications, the reason why joins are not supported by NoSQL databases because to join between two tables we have to make sure the variable linking between two tables, in our case document but as we know that NoSQL has a flexible schema which implies that the two documents might not have a common attribute so there is no guarantee that the key exists between two tables unlike SQL database where usually the join in SQL data is on primary keys, it is better to use NoSQL in applications where missing data can be tolerated and won not affect the business functionality.
Real Life application using both paradigms
The following examples are a non-exhaustive list of companies using SQL, Kaggle, Microsoft, Stack-overflow, Cisco, Walmart, Robinhood, Reddit, Uber, Netflix, Instagram, delivery hero, and Spotify. While the companies using NoSQL are Uber, Lyft, and delivery hero, Paytm, Accenture, Alibab travels.
A lot of these companies using a mixture of both databases depending on their needs and the goals they are trying to achieve.
Other interesting data models
There is a lot of data models that are totally different from the Relational and Document model, one of these models is the graph data model, the graph data model power comes within its ability to handle join operations in an efficient way unlike different data models like the relational which is not so efficient in handling an intensive number of join operations or document model which does not support joins.
The graph data model also commonly known as the whiteboard model, graph model organizes data points into edges and vertices, edge represent the entity while vertices represent the relationship between different entities, what makes graph model good in handling joins is the fact that entities are connected to through the vertices so if we need information about a different entity, we will trace the vertices connected to the desired entity then return the required information.
in this model, john and sally are entities and arrows are vertices.
hope you enjoyed the article, the conclusion is that a lot of people argue that NoSql is going to take over and SQL became obsolete, which is not true, SQL is a strong and reputable data model that proved its usefulness throughout the years, Do not use NoSql or any other data model if you do not have a reason to do so.
How Schema On Read vs. Schema On Write Started It All | Dell Technologies
Article originally appeared as Schema On Read vs. Schema On Write Explained. What's the difference between Schema on…
How are joins supported by SQL but not in NoSQL databases?
Answer (1 of 6): Joins are hard to do in any distributed database. Even on distributed SQL databases. It is not that…
Why developers like Microsoft SQL Server
See what developers are saying about how they use Microsoft SQL Server. Check out popular companies that use Microsoft…
Why developers like PostgreSQL
See what developers are saying about how they use PostgreSQL. Check out popular companies that use PostgreSQL and some…