The essential difference between the two teconologia is that one is based on schema (Relational) and the other is not (Nonrelational).
To work with an SQL database (Relational) the first thing that Cvoce needs to do is to design the database structure, that is, Cvoce cannot insert a data if it has not previously defined the "schematics" of the tables, while in Nosql (Non-relational) technology. this is not necessary.
Let’s take an example:
Suppose you wanted to store customer names and phones in a database.
In a relational bank, the first thing we would need to do is define the schema of the tables in the bank (define their structure), as we know that a customer can have more than one phone and that each one can have different amounts of phone numbers, the ideal would be to define 2 tables: One for the registration of the code and the name of the client and another for the records of your phones:
Table Client (Tabcli):
id, Integer
Nome, Character, 50
Table Phones (Tabtel):
id_cliente, integer
Fone, Character, 15
This way each client will have only one record in the table tabcli and at least one, or how many numbers it has in the table Tabtel. The link (or relation, of the term "relational") between a table and another would be made through the fields Tabcli.id -> Tabetel.id_client, so to present the information of a client would need to select-in the Tabcli table, and filter all records in the Tabtel whose id_client coresspondesse to id in the Tabcli.
Now let’s see how the same example would be registered in a no-sql database such as mongodb, in the first place Oce would not need to define a previous scheme to store the information, Oce would only need to make the record directly in a format that the database "understands"in the case of mongodb, json. In Mongo, the corresponding table is called Collections, so it would be enough:
db.clientes.save( {_id: 1, fones: ["123-4567", "456-7899"]})
To access, just locate the _id of the client and Voce will already have access to all the information of that client, without the need to access another entity of the bank and/ or creation of filters, etc.
The explanation above is well summarized, there are numerous other details both on the relational and non-relational side, in the first for example there are several elements to ensure the integrity and non-replication of the data, which were not mentioned.
Another central character of relational databases is exclusive use (see topic "It’s the end of SQL?) of the SQL language for access to the data while we are not relational that does not apply, but we need to pay attention to the fact that a non-relational database does not abhor SQL, in fact the term Nosql can induce the error of assuming that it is Not SQL, when in fact it is "Not Only Structured Query Language"
Advantages of non-relational banks:
The number one advantage of non-relational databases is scalability, of course the rigid schema of relational databases makes it difficult, for example, to increase a node in a database cluster, Another advantage is the flexibility of the structure which, in addition to making the scalability easier, facilitates the insertion and access to data. Another feature that may be seen as an advantage is the manipulation of data by object-oriented Apis while in the relational model only via SQL. One can also cite, as a disadvantage, the relative immaturity of Nosql.
Advantages of Relational Banks:
While in the non-relational model, consistency can be considered weak, in the relational model there is a strong consistency of data, one of the prices for this is the less flexible structure. Another advantage is reliability, relational models support property ACID (Atomicity, Consistency, Isolation and Durability), Another advantage of SQL is standardization and normalization. Finally one can cite as an advantage the maturity of SQL.
Who uses Nosql and why:
The main and crucial reason for choosing Nosql is scale, so what the big market "players" do is to choose areas where reliability and consistency can be, to some extent, ignored in favor of scalability to use this technology. It is important to realize that the best known Nosql banks in the market were created by these players.
Exactly because banks of the Nosql model avoid the ACID property, big players like Google and Facebook avoid using them in applications that require great consistency and reliability. Below I reproduce (of that link) a list of applications where non-relational models were used.
| Candidate | Usage | Tools |
|-----------|---------------------------------------|-----------------------|
| Facebook | Email search system | Cassandra (Apache) |
| Google | Used for generatin and modifying data | Big Table (By Google) |
| LinkedIn | Millions of reads an writes per day | Voldemor (By LinedIn) |
It’s the end of SQL?
The word "disruptive" is one of the most widely used words in technology and, according to Wikipedia, is a term describing technological innovation, product, or service, which uses a "disruptive" strategy, rather than "revolutionary" or "evolutionary", to overthrow an existing technology dominant in the market. On several pages of the nonrelational bank website mongdb it is possible to find references to this term alluding to (im)probable decay of the relational model.
Would the relational model be in danger if Nosql could achieve the same level of consistency and reliability? Would this be possible without losing its main advantages? What if the SQL model could implement some of the advantages of Nosql?
Fortunately the answer to the last question is that this is already happening, it was with a grateful surprise that I recently discovered that it is already possible to define JSON fields in at least one relational database, Postgresql.
Not Only SQL
I participated in a work done for a course in 2012, in which we present a brief summary about Nosql. That presentation can point paths for deeper search. See it in full screen.
Excellent explanation, congratulations!
– FabioR