SQL vs NoSQL or MySQL vs MongoDB

SQL or NoSQL? MySQL vs MongoDB? Which database is better? Which one should you use?

----------

----------

• And you should of course also follow @academind_real.

See you in the videos!

----------

[windar]

0:36 SQL
9:00 NoSQL
13:13 Differences

[aleksas_codebook]

I dont think I will ever be grateful enough for Maximilian. This man single-handedly taught me everything from HTML, CSS and basic JavaScript, all the way to Vue and React, Node.js, databases and REST API. Thanks to you I got a highly paying job, and can make anything that comes to my mind. Thank you sir from the bottom of my heart. :)

[rodrigo-xycg]

A key concept in this comparative analysis is consistency of information.

- SQL (Relational Databases): a good design (scheme and constraints defined correctly and transactions are used properly) allows the database engine to guarantee consistency based on that design.

- NoSQL: lower consistency of information (it is a responsibility of the developer to ensure consistency... some time this could be very difficult).

[scvscades]

Thank you for this! I've been tasked to build a DB, but wasn't sure which type to go with. I tried using MongoDB and I can see where it has it's advantages. After watching this though, an SQL DB is better for our needs.

[nicolasazoidis]

Man you knowledge base is beyond human scope...really. When i first started learning programming there where many times i coulnd't get you, after learning programming there a lot of times i realize how many miles ahead you are. RESPECT.

[bnmvbn]

This is hands down the most concise and relatable explanation of a SQL-like database vs a NoSQL-like database I have ever seen.

Random tips:
-A good intro to SQL is reading Chapter 2 of the official PostgreSql manual.
-As a frontend dev, it's easier to "pick up" NoSQL. Since NoSQL is literally a folder of JSON files that you can search(query) through.
-But, it's easy to dig yourself into a hole if you duplicate your data in several locations and then need to update that same piece of data.
-You can also hurt yourself when your not consistent with your property names. For example "first name" can be found as "f_name" or "firstName" in your NoSQL database
-Just be careful, and very consistent when using NoSQL.

For total beginners, I recommend to go with SQL and then migrate to NoSQL if needed.

Think of SQL-databases as a really powerful sportbike motorcycle with really good training wheels. It's safe and you probably won't outride the bike.

[Relsig]

Horizontally scaling SQL isn't very difficult but it requires a backend to do some extra work behind the scenes (which isn't terribly hard to program). Implemented properly and under certain conditions it can be slightly faster than NoSQL.
You can use Schemas with NoSQL, see tools like Mongoose. Mongoose also makes relations very easy with the populate function. If the data isn't likely to change frequently it would still be better to just nest the data you need and update it as needed for speed though.


So
SQL horizontal scaling: possible but more difficult than NoSQL.
NoSQL: Schema-optional with reverse-compatible changes via some well documented apis


Aside from those excellent video

[oubrioko]

Horizontal scaling (also called _scaling-out_ ) is challenging and can be inherently inefficient with a _shared-nothing_ SQL database like MySQL, as mentioned in the video. However, there *are* indeed _shared-storage_ SQL databases that are designed to dynamically scale-out (horizontal scale) seamlessly. This is accomplished by replicating the database _structure_ on each server node, but with virtual programmatic pointers in each table, rather than the actual rows (records) of data themselves. These pointers point to corresponding table structures on distributed Storage Area Networks (SANs) that contain the actual rows of table data. Given this complexity, an enterprise-grade dynamically scalable shared-storage SQL database solution like Oracle 18c is very expensive to acquire, implement, administer and support. During the mid-2000s, Larry Ellison used to love to brag about the horizontal scaling capability of Oracle's shared-storage SQL offerings verses IBM's DB2 shared-nothing SQL database.

[osvaldoguzman]

Another important thing to consider for SQL databases is the amount of time conceptualizing a SQL database takes. For an effective SQL db you need a proper ERR Diagram and schema that takes into consideration a ton of user interactions. One wrong step at the conceptualization phase and your whole relational system breaks. Similarly, the modification anomalies that may come from NoSQL can break your db, but to a more manageable extent IMO. When agile development reigns king, quick development with short conceptualizing phases means your better off with NoSQL despite the downside to writing-heavy applications. What do you all think?

[suyuro_]

God bless this "vs" videos they are so good.

[mbramante]

I really like this video with one singular exception.

When discussing relational databases at 1:48 minutes into this video the narrator says: "The database we typically use is a relational database that means we have a database which works with certain assumptions".
No other mention or explanation is given for this.
Also there is never a mention of NoSQL databases working "with certain assumptions".

I've designed/modeled and built relational databases for 19 years.
I base every relational database design on one thing: Rigorous due diligence in requirements discovery and analysis.

This means:
1) Requirements
2) All the requirements
3) Nothing but the requirements

The one thing I NEVER base my relational designs on is "assumptions". No good relational database design should ever be based on assumptions.

[akmalatkhamov]

Tremendous explanation. I have spent 3 days reading tons of information about differences between SQL and NoSQL, and have understood less than I expected, but this video made everything straightforward. Thanks to the author! Great work!

[fabriziodutto]

There are special commands so called "choins" @8:31 :-) I really love this german accent! Thank you for this comparison, very interesting and complete.

[TheDragonlove]

Relations = Tables (Product Table)
Relationship = Relationship (One to One)

Relation != Relationship
that's the db language as we learnt it from our teachers

[gjermundification]

9:16 mongoDB may be the nosql with most tutorials, then again if you run postgres, mongodb and couchdb in strace, mongodb spends like 6 times the amount of resources to achieve the same performance compared to postgres or couchdb.

[mysterria_com]

It's actually not about SQL vs NoSQL but relational vs non-relational. SQL databases come with a lot of constraint and behaviors (triggers) and if your data is highly relational, you will have an advantage using SQL databases maintaining your data structural integrity. On the other hand NoSQL databases are very restricted in relational integrity enforcement tools, but they are faster, easier to operate and learn and are very convenient for specific tasks.

In general, use relational database if you're not sure which type of DB to go with. It might require some extra planning but won't lead you to data integrity issues and migration to NonSQL will be mush easier.

At the point you face the need of sharding you will surely be well aware of what type of DB you need and how to shard your data well. So I'd not worry about scaling at this point.

[JohnWeland]

We use an SQL database at work specifically PostgreSQL. Our "rules" for our schema all tables need a primary key as a sequence that is either called seq or id. If that tables p_key is not referenced in another table we call it seq if another table does use it, its called id so a user table would have a column id, then on the table referencing there would be a sequence and a column called user_id.

All of out many to many tables we call tablename_xref (xref for cross-reference) so just looking at the database it makes a ton of sense. we also add control columns on every table prefixed with ctl we have an insert user, insert time, update user, update time the times are stored as dttm (time with timezone). any anytime a user inserts data or updates data its reflected in the control columns.

[MrAnonimR]

Hi,


thank you for putting the effort and time to explain in such understandable way the differences between SQL and NoSQL. I appreciate your effort ! Good Luck!

[desertpillar]

Thanks for a great general comparison... I know this is old, but thought I'd mention one thing that I think is overlooked in this video although technically correct. Specifically regarding relations and schema consistency. While you are correct in saying that it is not directly supported in Mongo, this responsibility is instead handed over to the ORM layer. Typically, at least in Rails with Active Record, you add all the schema enforcements and relational requirements in that layer instead. By doing that you eliminate most of the downsides you mention regarding data consistency.

One other key feature that I think should be mentioned too is that you can create much more advanced data structures in the documents themselves. This is a very simple example, but lets say you wanted to quickly wanted to know which users ordered a specific product. One way to solve that would be to have an array of user_ids on the product collection which essentially acts as a has_many relationship. When displaying products you could easily describe how many users bought this product and even show if friends of the user bought the product (provided you have a collection for that data too). Maybe a stupid example, but hopefully you get the idea.

I would say that the biggest downside to using mongo is if you have a lot of requirements to run group by queries. Although it is possible in mongo with aggregations, it is not as straight forward.

For me, unless I'm writing a banking application, I would select mongo for every web application I would build. :)

[grantharmer]

Great video. One of the other key things SQL databases tend to have over NoSQ databases are transactions. i.e. ACID (Atomicity, Consistency, Isolation, Durability) support. But, there is an argument that, if you structure your NoSQL documents well, ACID is not needed