In fact the "relational" part of database does not refer to the relations between different tables, but to the relational model as laid out by E.F codd. In this model, tables are called Relations and rows are called tuples.
I'm sure E.F codd was a smart guy, but I think it's misleading to say that all tables should be called relations. SOME tables represent a set of relations while other tables represent a set of entities. I also don't like the tuple term. "Tuple" means a thousand different things now.
Was really stuck with what setup to choose for a new project. I use SQL at work and NoSQL for side projects and have always felt more comfortable with NoSQL. Your last point about choosing whatever you're most comfortable with really resonated with me, great video!
There are reasons why big companies use nosql for one thing and sql for another. Google Docs will probably use nosql to store your documents since most you do is write to it and only read the document once to start editing it. As a company its important because you can reduce costs since the performance is better but you also use less resources. Thats also why autoscaling is used to reduce useless resources.
Your explanation are nice If you show slides and image to explain it will be much better and much easier for beginners to relate things you say and understand better
Give taking your own notes a try! Serious, listen to a video more than once if needed, pause and take a short note. Much better understanding AND better glued in memory, than just "consuming"/watching someone's slides! 🖖🏻👍🏻☕
So to sum-up SQL - fast to read - you can count on constant a format NoSQL - fast to write - hard to update - better at handling lots of connections at the same time (why?) - better at scaling - good for unstructured data
SQL can handle many connections (you made it sound like SQL can only manage a handful of connections). If there is an appearance of “slowness” it’s likely related to the isolation level \ locking, which can be managed with good database design (9/ 10 times perf issues are attributable to poor developer choices). The choice between the two systems should be about isolation level requirements , scale (data volume \ geo-distribution) and the actual data model being stored. If you’re dealing with high transaction financial data, your likely not gonna go no sql. Likewise, if your storing IOT data then no sql is going to be better. If you’re never going to shard your data, mongodb is not worth it as SQL will outperform it.
A legit conclusion. Both technologies are proportionally good. The SQL allows vertical scaling, while NoSQL - horizontal scaling. The SQL simplifies the usage of MVC, MVVM, Object Validation and bindings, while the NoSQL simplifies the ability to make changes into projects (very useful for e-commerce dbs). The idea to use JSON data as TEXT in SQL is promising as something intermediate.
I've been dabbling in SQL a lot more lately. I'm actually considering building my newest project using it as the database. Most likely going to go with PostgreSQL. Thanks for the content Kyle. Much love my friend!
This actually really helped me understand both! Currently I’m learning MySQL with php and I may consider using react with it. I say MySQL I enjoy for your explanation of the great structure and columns and I care about readability. Though I may learn mongodb in larger scale applications in the future. Since mongodb sounds great for big projects
This was helpful. It would be even more helpful if you provide brief reasons for each claim on why SQL or NoSQL is better. For example, why is it usually quick to write but harder to read from a NoSQL DB?
i think its because NoSQL you can just shove objects in the database because order doesnt matter since the processing is done upon queries, hence why its harder to read.
it's not entirely accurate either - it depends on the scenario - there are some query examples that have nosql being 100x faster at reading compared to a sql query that involves multiple joins compared to a nosql read where it's just pulling a full document based on id whether sql or nosql is better fully depends on use case
Among the people who talk about programming on youtube, I prefer your approach. You always bring the subject well summarized, contextualized and didactic. It is complex to do simple things, isn't it? ... Only those who have very clear reasoning can do this. The simple fact that you put the noSQL image as branches of a tree, already shows your skill. Keep it up... and you will be helping to build a solid foundation for the evolution of technology.
Imo you missed the most important feature of sql databases, which is ACID transactions. That's the fundamental stone of pretty much every enterprise application
True, although the larger enterprises have been transitioning to microservices and cloud architectures. Due to the CAP theorem, these distributed solutions are ACID non-compliant*.
Hey man, usually a fan of the videos but I feel like this one fell pretty short. Alot of surface explanation without any real world examples which I feel would help extremely
An example: Suppose you are storing customer shipping addresses. On a SQL database, you might have columns for house number, street, city, state, zip code; which works for US addresses, but not necessarily for addresses in other countries. On MongoDB, you could format their address differently depending on which country they are in. But the database would not check the address is in the correct format, it would accept anything, you would need to do your checks in the application logic.
This is first unbiased video I have watched till now. Everyone else telling that NoSql is just better and whatever advantage they tell can also be applied on SQL
bigger companies use tons of different database types for different purposes but imo if u learn how to optimize SQL databases really well then u can apply these concepts to the other types
Man, you speak very fast but with a excellent pronunciation. It is really good for me, since I'm learning english. xD. Excellent comparative, and thank you for comment about Json in PostgreSQL.
If you use it properly then there are zero joins in NoSQL database and reading is faster than SQL. Cost of 1 GB storage is super low. So you can repeat data without worry.
4:54 Isn’t one of the benefits of a nosql database like mongodb is that you optimize for reads by having denormalized data at the cost of more costly writes?
I'd lean towards a NoSQL database is starting a new project with potentially large amounts of data. The biggest weakness isn't reading data, it's searching data, this problem is true for both paradigms. Most large applications get around this by using an index like SOLR or Elastisesrch to grab the UID for a row and then query the database with those UIDs. That is very responsive. What really makes the NoSQL approach attractive is you're not bound to a schema that requires a lot of work to change. If you want to change your data structures a bit, you just have to change the mappers.
MySQL is great for correlational studies, especially for routine data. However, it takes time to organize the tables. No-SQL is great for chaotic and dynamic based data. Think of data tracking a bipolar person.
Sql generally has more advantages. For example it offers you ACID approach. You can use transactions if you want your data to be coherent. Also you can use NoSql approach in a Mysql database if you want. But you cannot expect a NoSql data to be coherent. So selecting Sql over NoSql will be a good decision if there is no special situations.
"To sql or not to sql, that is the question. Whether tis nobler in the mind to suffer the keys and joins of outragous databases, or to take arms against a sea of tables and by opposing end them."
SQL: for times you need to read & write data NoSQL: for times you want to hoard json that you don’t want to bother parsing and you rarely need to look anything up.
Hello Kyle, big fan of your videos ! I don't understand why wou say that non-relational databases can be more "fuzzy" because the data written goes though less checks compared to a SQL db. If I take MongoDB for example you have to create a model that define what kind of data to expect (and possibly further restrictions) and to setup some validation criteria that data has to go through to be stored in the database. Have a nice day.
My home automation (power usage, solar generation) is in MongoDB. First few years it was in SQL-Server, then switched to MongoDB. I'm storing about 130 samples per minute for the past 5 years, I aggregate the date / device into 1,15,30,60 min, 24, month, year. It's simply flawless.
i think you are missing some key points. almost everyone is dealing with relational data (SQL). NoSQL takes the responsibility for data consistency away from the database, and puts it on all applications using the database, which is not ideal. i like most of your other videos
Hello! Coming from NoSQL (Mongo) to SQL What I don't like with Mongo is that if you delete a document (A) in one model that references another document from another model (B), then B is not deleted, you need to handle this manually If I understand well, there is no such problem with SQL databases ?
It depends on DBA. Problem that you mentioned is called referential integrity. If you don't implement correct technique during the design you might get a situation when a row from table A is deleted and another row in table B still references deleted row in table A. Thus, you will end up with inconsistent or redundant data. SQL server for example uses a way to CASCADE the changes (either update or delete) by primary key, this way all the references to the deleted or update data will propagate through out the database :)
MongoDB has full ACID transactions across shards, also atomic transactions. Consistent across multiple DBs in a cluster by setting write concern to majority
I had a talk with a software architect who completely messed up my head by giving me multiple reasons on how a nosql is better than mysql for any large scale app. His arguments were mostly on how mysql can be a headache on architectural level when an app grows.
Ummm... he is not a software architect; if an app grows, you can create more tables, you can "alter table", just matter of seconds. The freedom he/she lets you believe you have in no-sql will be a nightmare very soon....
I still do not understand why would I use noSQL when I could simulate it in mySQL by (for example) adding a text field that contains some json. Is ti much faster? Or is there something else I'm missing)
I've always heard people hating on mongo, like theo, but I've never quite understood why? I like postgres and find it to be pretty good, but a lot of times it feels stricter and slower, in my experience. I'm far from a database expert, but I really find it odd that people are so obsessed with the "relational" model. As if you can't essentially use foreign keys or do joins in mongodb. You pretty much can, though they might go by different names, and I've heard many people point out how silly a JSON oriented database is, but I can't really see an argument for why excel spreadsheets are so much better. I don't see anything wrong with either approach, but I'm struggling to see a lot of advantages for using antiquated SQL dbses other than certain key performance metrics and data integrity. That being said, it's just weird because NOSQL gets a lot of hate, but I've yet to hear the legitimate criticisms of it. I mean, I'm sure there are some, but I don't really understand why people think that data can't have relationships in MongoDB. I mean, you could argue that the structure of SQL databases causes them to more often return the data that you are looking for, but it also creates a lot of complexity in rules, functions, schemas, writing, etc. On the flip side, with NOSQL it always seems like the structure of your queries is a lot more important than the structure of your data. The end result tends to be pretty similar, but the approach is quite different. Is this just the angry grumblings of devs that don't like to change their process for doing things or are there greater issues with MongoDB "underneath the hood" so to speak? I'd really like to know because on the surface most of these arguments seem kind of arbitrary unless you get into the details. Good video. I mostly agreed with the points. I could certainly see the devil being in the performance metrics, but it doesn't really seem to be in the capabilities.
Everything I've been reading and watching has been saying an opposite conclusion, that nosql is better for reads while sql is better for writes. This is all confusing me, but what I got was nosql expects you to duplicate data wherever you need it. So when making requests, all the relevant data you need is right there and the database doesn't have to do any extra searching for it. Sql wants you to have data in one place, and just make references to it wherever you need. So if you ever want to update data, you just do it in that one place it's defined and it'll be accessible everywhere. That'd make sql way better for writing data (as you only have to do it in 1 place), and nosql way better for reading data (as all your relevant information is already together) Can someone correct if I'm wrong, but isn't this the exact opposite of what this video is saying?
I wonder, what about encoding foreign characters? I made a project with MySQL and I had lots of problems with encoding Japanese (language learning website). I hope other databases are set to support utf-8 by default. I had to set up encoding in like maybe 4 places for it to work...
Video title is click bait & I feel you didn’t explain WHY the different NoSQL exist. What issue are they each trying to solve (i.e. why would they out perform a solution implemented in SQL)? NoSQL is a collection of DB paradigms (key-value, docstore, search engine, graph, etc). It would have been good if you had explained the key points that differentiate each type… imho
Hi Web dev Simplified; I would like to create my first CRUD app learning REACT at the moment. Soon I will start learning node.js and afterwards MySQL. I know how to perform basic queries within tables in a database but not between multiple tables. I am familiar with creating new database and creating new tables too. My question is I am decent on the front end could you provide resources which teach how to use a backend technology alongside MySQL or even postgreSQL to store your data for a basic blog app. My thoughts are to create a blog app which will allow a maximum of at least 10 people to create a very simple profile and post messages on a board. No securities, no cookies something locally from my hard drive. Figured I start small and work my way up. Any guidance would be appreciated.
I want to create a database in order to receive data from the Arduino meteorological monitoring device (temperature - irrigation speed - humidity). The degree of measurement is sent every 30 minutes, so what is the best type of database
@@AravindVNair I'm in the same boat, I absolutely love MySQL and Firebase and I've been hoping for a long time that something like that would exist. I almost threw up from excitement when I found out about supabase
William Kylespeare
😁😁
hahahaha
Kyliam Cookspeare
@@blessingseverywhere3140 lmao. Way more creative than mine
@@dooddotjs3910 I don't care if it's more creative than yours or not, my friend. I just want you guys to smile.
the first 15 second I felt like I clicked the wrong video 😂
lol
Lmao
When he said 'To sequel or not to sequel that is the question' i was in tears. Truly one of the best lines of all times
In fact the "relational" part of database does not refer to the relations between different tables, but to the relational model as laid out by E.F codd. In this model, tables are called Relations and rows are called tuples.
I'm sure E.F codd was a smart guy, but I think it's misleading to say that all tables should be called relations. SOME tables represent a set of relations while other tables represent a set of entities. I also don't like the tuple term. "Tuple" means a thousand different things now.
Was really stuck with what setup to choose for a new project. I use SQL at work and NoSQL for side projects and have always felt more comfortable with NoSQL. Your last point about choosing whatever you're most comfortable with really resonated with me, great video!
There are reasons why big companies use nosql for one thing and sql for another. Google Docs will probably use nosql to store your documents since most you do is write to it and only read the document once to start editing it. As a company its important because you can reduce costs since the performance is better but you also use less resources. Thats also why autoscaling is used to reduce useless resources.
Your explanation are nice
If you show slides and image to explain
it will be much better and much easier for beginners to relate things you say and understand better
Give taking your own notes a try! Serious, listen to a video more than once if needed, pause and take a short note.
Much better understanding AND better glued in memory, than just "consuming"/watching someone's slides! 🖖🏻👍🏻☕
@@maxfrischdev Yeah right
@@maxfrischdev expert tip, thanks Max.
bro sold his all furniture to buy a guitar 🎸
I always get confused on these two DBs but you explanation was very clear and made a lot of sense
So to sum-up
SQL
- fast to read
- you can count on constant a format
NoSQL
- fast to write
- hard to update
- better at handling lots of connections at the same time (why?)
- better at scaling
- good for unstructured data
3:05 Redis saves data to the disc periodically and loads it on startup.
But storage persistance strategies can be modified.
SQL can handle many connections (you made it sound like SQL can only manage a handful of connections). If there is an appearance of “slowness” it’s likely related to the isolation level \ locking, which can be managed with good database design (9/ 10 times perf issues are attributable to poor developer choices). The choice between the two systems should be about isolation level requirements , scale (data volume \ geo-distribution) and the actual data model being stored.
If you’re dealing with high transaction financial data, your likely not gonna go no sql. Likewise, if your storing IOT data then no sql is going to be better. If you’re never going to shard your data, mongodb is not worth it as SQL will outperform it.
A legit conclusion. Both technologies are proportionally good. The SQL allows vertical scaling, while NoSQL - horizontal scaling. The SQL simplifies the usage of MVC, MVVM, Object Validation and bindings, while the NoSQL simplifies the ability to make changes into projects (very useful for e-commerce dbs).
The idea to use JSON data as TEXT in SQL is promising as something intermediate.
I've been dabbling in SQL a lot more lately. I'm actually considering building my newest project using it as the database. Most likely going to go with PostgreSQL. Thanks for the content Kyle. Much love my friend!
This guy legit looks better than most of the male models appearing on product advertisements and could easily land ads showcasing hair products.
He reminds me of the Winklevoss twins for some reason lol (the movie actors not the real ones)
Nice, quick explanation and that top-left corner perfectly aligned with room’s corner line👍
This actually really helped me understand both! Currently I’m learning MySQL with php and I may consider using react with it. I say MySQL I enjoy for your explanation of the great structure and columns and I care about readability. Though I may learn mongodb in larger scale applications in the future. Since mongodb sounds great for big projects
Ew php
@@Rust_Rust_Rust 😆 🤣 😂
@@Rust_Rust_Rust hahaha. your comment
@@Rust_Rust_Rust Most loved language not loving back
Please make this series of comparing different technologies like SSR vs CSR, React vs Vue, Tailwind vs Bootstrap etc
That's a good idea
@@WebDevSimplified A humble request for more TypeScript content please _/\_
This was helpful. It would be even more helpful if you provide brief reasons for each claim on why SQL or NoSQL is better. For example, why is it usually quick to write but harder to read from a NoSQL DB?
i think its because NoSQL you can just shove objects in the database because order doesnt matter since the processing is done upon queries, hence why its harder to read.
it's not entirely accurate either - it depends on the scenario - there are some query examples that have nosql being 100x faster at reading compared to a sql query that involves multiple joins compared to a nosql read where it's just pulling a full document based on id
whether sql or nosql is better fully depends on use case
Because NoSQL is for the times you don’t need to READ the data
Among the people who talk about programming on youtube, I prefer your approach. You always bring the subject well summarized, contextualized and didactic. It is complex to do simple things, isn't it? ... Only those who have very clear reasoning can do this. The simple fact that you put the noSQL image as branches of a tree, already shows your skill. Keep it up... and you will be helping to build a solid foundation for the evolution of technology.
Imo you missed the most important feature of sql databases, which is ACID transactions. That's the fundamental stone of pretty much every enterprise application
True, although the larger enterprises have been transitioning to microservices and cloud architectures. Due to the CAP theorem, these distributed solutions are ACID non-compliant*.
Hey man, usually a fan of the videos but I feel like this one fell pretty short. Alot of surface explanation without any real world examples which I feel would help extremely
An example: Suppose you are storing customer shipping addresses.
On a SQL database, you might have columns for house number, street, city, state, zip code; which works for US addresses, but not necessarily for addresses in other countries. On MongoDB, you could format their address differently depending on which country they are in. But the database would not check the address is in the correct format, it would accept anything, you would need to do your checks in the application logic.
This is first unbiased video I have watched till now. Everyone else telling that NoSql is just better and whatever advantage they tell can also be applied on SQL
Really nice start with the William Shakespeare
I thought it was an ad
That sloved my confusion... thanks 😊
And im also waiting for Javascriptsimplified course to reopen registration.
bigger companies use tons of different database types for different purposes but imo if u learn how to optimize SQL databases really well then u can apply these concepts to the other types
Correct me if I'm wrong but if you're familiar with DBMS concepts you can adapt to both SQL and Nosql right?
100% no brainer you need to how to connect foreign keys joins left join more specifically
Sure!
Man, you speak very fast but with a excellent pronunciation. It is really good for me, since I'm learning english. xD. Excellent comparative, and thank you for comment about Json in PostgreSQL.
If you use it properly then there are zero joins in NoSQL database and reading is faster than SQL. Cost of 1 GB storage is super low. So you can repeat data without worry.
Hmmm, I'm storing json data to MySQL atm.
yup you can store anything and then just parse the string back into JSON....
Win win haha.
@@chizuru1999 How are you going to search through the string then? With NOSQL you can search and select on the Objects
There is always some rebel who do this. LMAO
@@chizuru1999 That is not a win win. Parsing data takes time, decreasing performance. If you want speed, actually use columns and rows.
@@hnccox how can you search on select objects in nosql.. nosql doesn't have schema and there would be only 1 unique key to differentiate the data
4:54 Isn’t one of the benefits of a nosql database like mongodb is that you optimize for reads by having denormalized data at the cost of more costly writes?
I'd lean towards a NoSQL database is starting a new project with potentially large amounts of data. The biggest weakness isn't reading data, it's searching data, this problem is true for both paradigms. Most large applications get around this by using an index like SOLR or Elastisesrch to grab the UID for a row and then query the database with those UIDs. That is very responsive.
What really makes the NoSQL approach attractive is you're not bound to a schema that requires a lot of work to change. If you want to change your data structures a bit, you just have to change the mappers.
I love your channel!!! Can't stop watching. All your content is the best ☺️
MySQL is great for correlational studies, especially for routine data. However, it takes time to organize the tables.
No-SQL is great for chaotic and dynamic based data. Think of data tracking a bipolar person.
oh man, you brought Sheksphere....
love you man.
ah yes, sheksphere
Shreksphere
best overview and comparison i've got so far! thanks a lot! 👍
I use Mongo cause the logo looks cool 😎
ahahahah, im switching to ruby cause it sounds cool and logo is just so beautiful
@@arthurweasley5857 nobody uses ruby nowadays in the industry, better use mongodb or mysql
I absolutely love the intro and the entire explaination
you missed one of the main points, the acid vs base model.
most of the time, I see those models as one of the main decision maker on what to use.
Sql generally has more advantages. For example it offers you ACID approach. You can use transactions if you want your data to be coherent. Also you can use NoSql approach in a Mysql database if you want. But you cannot expect a NoSql data to be coherent. So selecting Sql over NoSql will be a good decision if there is no special situations.
MongoDB supports transactions
Really appreciate the way you explained this controversial topic. Keep it up bro
I came here to appreciate PostgreSQL and your Ibanez lady
Huge thanks. I think if you add a table of comparing these two type would be much better for summarizing.
Love this video! I greatly appreciate the perspective!
a video I wish I had watched when I was making my research on the topic a while ago
omg I swear I just thinking about this question in few minutes before open youtube and then... this happened
Have you ever tried thinking of a couple of millions of dollars?
You absolute dreamer.
I know it's ridiculous right. but the same time it was mindblowing to me
But, you know.. I couldn't hold back my own thoughts, it just randomly passed
@@elmyllo4219 may be it’s not that ridiculous. 😂
"To sql or not to sql, that is the question. Whether tis nobler in the mind to suffer the keys and joins of outragous databases, or to take arms against a sea of tables and by opposing end them."
SQL: for times you need to read & write data
NoSQL: for times you want to hoard json that you don’t want to bother parsing and you rarely need to look anything up.
Thank you man, is just what I was looking for!
That's the explanation I needed. Thanks a lot man.
Um, Sql and NoSql are opposite ? Not so, just somewhat different take on structure vs flexibility, both are records of data.
What is Chris Pine doing here ?
Also sick Jackson ,just chillin in the corner
Hello Kyle, big fan of your videos ! I don't understand why wou say that non-relational databases can be more "fuzzy" because the data written goes though less checks compared to a SQL db. If I take MongoDB for example you have to create a model that define what kind of data to expect (and possibly further restrictions) and to setup some validation criteria that data has to go through to be stored in the database. Have a nice day.
The thing with mongodb is that you DON'T HAVE TO define models, but you CAN if you want to.
For Internet of Things like Smart Energy Meters, which will be a better solution for storing the data?
i personally would go with MySQL/MariaDB, but NoSQL like ElasticSearch/Apache Solr is fine too - this heavily depends on your application needs.
In my exp (only done small projects at university/intership), noSQL are a little better for IoT but it still depends on the application
My home automation (power usage, solar generation) is in MongoDB. First few years it was in SQL-Server, then switched to MongoDB. I'm storing about 130 samples per minute for the past 5 years, I aggregate the date / device into 1,15,30,60 min, 24, month, year. It's simply flawless.
Amazing explanation , always motivates me to learn futher
MySQL also supports JSON columns.
Play something with that guitar
i think you are missing some key points. almost everyone is dealing with relational data (SQL). NoSQL takes the responsibility for data consistency away from the database, and puts it on all applications using the database, which is not ideal. i like most of your other videos
how can i work on SQL as Team in local host database ?
Best practice for me : Sql for Database and Firebase Remote Config as a json config for the App
Hello! Coming from NoSQL (Mongo) to SQL
What I don't like with Mongo is that if you delete a document (A) in one model that references another document from another model (B), then B is not deleted, you need to handle this manually
If I understand well, there is no such problem with SQL databases ?
the video says that SQL pretty slow to query if there are a lot of users accessing it
It depends on DBA. Problem that you mentioned is called referential integrity. If you don't implement correct technique during the design you might get a situation when a row from table A is deleted and another row in table B still references deleted row in table A. Thus, you will end up with inconsistent or redundant data. SQL server for example uses a way to CASCADE the changes (either update or delete) by primary key, this way all the references to the deleted or update data will propagate through out the database :)
the Zach Morris of web dev
thanks your explanation is very good. SQL is the best for relational data.
You missed two important things:
1/ Transactions
2/ Consistency
MongoDB has full ACID transactions across shards, also atomic transactions. Consistent across multiple DBs in a cluster by setting write concern to majority
@@Mark.Brindle Thanks, I wasn't aware of ACID transactions in MongoDB.
Hey what do you think of services like Firebase in context of whether or not it'd be the future of database? Also is the pricing worth it?
I had a talk with a software architect who completely messed up my head by giving me multiple reasons on how a nosql is better than mysql for any large scale app. His arguments were mostly on how mysql can be a headache on architectural level when an app grows.
Ummm... he is not a software architect; if an app grows, you can create more tables, you can "alter table", just matter of seconds. The freedom he/she lets you believe you have in no-sql will be a nightmare very soon....
Fast Fast and very every useful. Thanks
Nearing 500k subs! What an achievement!
Thanks!
@@WebDevSimplified This escalated quickly
Kyle, you're great teacher!
If i use a SQL database as a NoSQL the performance would be the same? For example, using PostgreSQL Json column.
Kyle, I never thought to ask.. did you do the intro riff yourself??
I like your keyboard typing sounds , Can I ask you for a link on amazon for this keyboard? Thank you. : )
I still do not understand why would I use noSQL when I could simulate it in mySQL by (for example) adding a text field that contains some json. Is ti much faster? Or is there something else I'm missing)
I liked that intro
I've always heard people hating on mongo, like theo, but I've never quite understood why? I like postgres and find it to be pretty good, but a lot of times it feels stricter and slower, in my experience. I'm far from a database expert, but I really find it odd that people are so obsessed with the "relational" model. As if you can't essentially use foreign keys or do joins in mongodb. You pretty much can, though they might go by different names, and I've heard many people point out how silly a JSON oriented database is, but I can't really see an argument for why excel spreadsheets are so much better. I don't see anything wrong with either approach, but I'm struggling to see a lot of advantages for using antiquated SQL dbses other than certain key performance metrics and data integrity. That being said, it's just weird because NOSQL gets a lot of hate, but I've yet to hear the legitimate criticisms of it. I mean, I'm sure there are some, but I don't really understand why people think that data can't have relationships in MongoDB. I mean, you could argue that the structure of SQL databases causes them to more often return the data that you are looking for, but it also creates a lot of complexity in rules, functions, schemas, writing, etc. On the flip side, with NOSQL it always seems like the structure of your queries is a lot more important than the structure of your data. The end result tends to be pretty similar, but the approach is quite different. Is this just the angry grumblings of devs that don't like to change their process for doing things or are there greater issues with MongoDB "underneath the hood" so to speak? I'd really like to know because on the surface most of these arguments seem kind of arbitrary unless you get into the details. Good video. I mostly agreed with the points. I could certainly see the devil being in the performance metrics, but it doesn't really seem to be in the capabilities.
With some illustration and diagram the video would have been much more interactive and interesting
Make video about mysql or mongodb with redis as a cache
Amazing explanation sir!
it's not about comfortability. it's about cap theorem.
Everything I've been reading and watching has been saying an opposite conclusion, that nosql is better for reads while sql is better for writes.
This is all confusing me, but what I got was nosql expects you to duplicate data wherever you need it. So when making requests, all the relevant data you need is right there and the database doesn't have to do any extra searching for it. Sql wants you to have data in one place, and just make references to it wherever you need. So if you ever want to update data, you just do it in that one place it's defined and it'll be accessible everywhere.
That'd make sql way better for writing data (as you only have to do it in 1 place), and nosql way better for reading data (as all your relevant information is already together)
Can someone correct if I'm wrong, but isn't this the exact opposite of what this video is saying?
I will learn both of these.
Is there some morse code or som'n in how much he's blinking?
Awesome, thank you.
I wonder, what about encoding foreign characters?
I made a project with MySQL and I had lots of problems with encoding Japanese (language learning website). I hope other databases are set to support utf-8 by default.
I had to set up encoding in like maybe 4 places for it to work...
you could specify charecter encoding when creating column
Video title is click bait & I feel you didn’t explain WHY the different NoSQL exist. What issue are they each trying to solve (i.e. why would they out perform a solution implemented in SQL)? NoSQL is a collection of DB paradigms (key-value, docstore, search engine, graph, etc). It would have been good if you had explained the key points that differentiate each type… imho
Watched the rest of your video, is NoSQL databases easier to use in comparison to MySQL?
Definitely need some images, slides during the explanations.
“The money you enjoy wasting is not wasted money.”
- JRR Tolkien (The Chronicles of Narnia)
PostgreSQL | Golang.
A man of culture
Everybody in SQL be gangsta till they have to deal with user-defined models, complex migrations or horizontal scaling.
Just depends on what your app needs.
Hi Web dev Simplified; I would like to create my first CRUD app learning REACT at the moment. Soon I will start learning node.js and afterwards MySQL. I know how to perform basic queries within tables in a database but not between multiple tables. I am familiar with creating new database and creating new tables too. My question is I am decent on the front end could you provide resources which teach how to use a backend technology alongside MySQL or even postgreSQL to store your data for a basic blog app. My thoughts are to create a blog app which will allow a maximum of at least 10 people to create a very simple profile and post messages on a board. No securities, no cookies something locally from my hard drive. Figured I start small and work my way up. Any guidance would be appreciated.
I want to create a database in order to receive data from the Arduino meteorological monitoring device (temperature - irrigation speed - humidity). The degree of measurement is sent every 30 minutes, so what is the best type of database
influxdb
sorry love your vids super strong content but wasn't the quote from hamlet, or was that part of the joke ??
thank you for this!
Everybody going on about "are you a sequel type, or an ess-cue-ell type?", and I'm here having pronounced it "squeal" for the past 15 years...
This dude deserves to be the next Peter Parker (a.k.a. Spiderman). Hollywood, are you listening ?💡💡📢📢📢📢📢
thanks
I use firebase so I am "obliged" to use nosql. I would love if there was a SQL equivalent of firebase xD
Check out Supabase
@@AravindVNair I didn't know about that one. Thanks for telling me about it:-)
@@migueldomingos4570 Happy to help! :)
@@AravindVNair I'm in the same boat, I absolutely love MySQL and Firebase and I've been hoping for a long time that something like that would exist. I almost threw up from excitement when I found out about supabase
@@bobDotJS Glad you found it useful! :)
Other than scalability n maybe high performance in specific cases SQL beats No SQL any day
i was like woah where the hell am i in the first 10 seconds