You can think of a regular SQL database as a list of vectors. In an SQL database, each vector must have the same length and carry the same kind of data at the n-th index:

[ // the database itself is a "list of vectors"
  ["string", false, 3.14] // each row is a fixed-length "vector"
  ["another", true, 2.781828] // values at a given "column" must all have the same meaning
]

In a NoSQL database, no such rules apply. Rows can have any number of elements and hold any kind of data. This means that "column headers" will be different for each row, as well. Note that this is a general rule of thumb for NoSQL databases, but there are many different kinds of data storage mechanisms for NoSQL.

In general, NoSQL is more flexible than SQL and the particular "flavor" of NoSQL database that you need is dependent on the constraints of your problem. NoSQL can be faster than regular SQL for a particular problem set, but generally it is seen as slower and more error prone, due to the (small) possibility of "stale reads" (where data that is scheduled to be updated has not yet been updated when the user reads that data).

 

Second sentence, did you mean SQL instead of NoSQL?

 
 

A very clear answer, thank you very much.

 

This is a bit of tricky question, because the typical characteristics of NoSQL databases can be a pro or a con depending on what you want to do.

I think the single biggest idea behind NoSQL databases is that it is easier to scale them to more users (horizontal scalability). This is done by adding more servers rather than by increasing the capacity of an existing server. The downside to this is that you don't get the same guarantees with transactions that you get with (relational) SQL databases. Different users may see different versions of the same data, though usually for short periods of time - this is called "eventual consistency."

You probably don't want to use a NoSQL database to handle banking transactions. You could end up with a situation where you transfer money from one account to another, but the money appears to be both in the new account and the old one, or that it disappeared from the the old account, but isn't in the new one yet.

In really big internet applications, say social media, being able to scale is the most important thing, and having data consistency across all users isn't as valuable: Maybe I see your latest tweet, but someone else won't see it for another minute.

 

So, is it impossible, or infeasible, to implement eventual consistency with SQL databases? Is there something fundamental to how SQL DBs work that makes this difficult? If so, it seems like it would be a bummer if the problem you're solving is structurally more appropriate for SQL, but you need it to run at a very large scale and don't need the immediate consistency

 

There is such a thing as distributed relational databases, known as NewSQL. In fact, they seem to offer stronger guarantees than eventual consistency (in hopefully rare cases, they'll compromise on availability). For instance, Cloud Spanner, NuoDB.

Huh, that's super interesting! I'll have to dig deeper on that one

 

I'd suggest you consult Wikipedia on that matter and read the dynamo paper. The answers here so far are not helpful, some are plain wrong and there is no single concept that the magnitude of nosql databases share, despite they might not use sql.
But that alone says nothing.
Cassandra speaks something close to sql, close enough to make you fail when you discover the differences to relational database.

 

I'm sure @helenanders26 would have something to say about this, though.

Classic DEV Post from Apr 4

Design Patterns in Java

I thought it would be a fun to write a series of blog posts looking at differen...

Junior QA Tester of C# and Salesforce Applications. Learning C#, Python and Javascript. Game Developer wannabe. Writing articles to solidificate my wisdom.