The' when to use what' section was really helpful and just when I thought it couldn't get any better, you included a 'how to pick' section. Good job! Thank you.
Finally!!! I've been looking for a straight to the point video on relational vs non-relational database and this video explains it succinctly and even more. Thanks a bunch
I had to login to youtube just to subscribe to your videos. I really like them, easy to follow and very relevant. Thank you for these wonderful videos.
Finally I find what I looked for. It is quick and simple and clear explanation and I looked for this short and complete answer it for my aws interview. Thanks thousands
Great summary. The main motivation for development of non-relational databases is around scaling. A relational database scales out reasonably well for reads (there is a clue in the name "Read Replicas"), but there is still a single master, hence a bottleneck for writes. The design of KV stores was largely to get around this problem. Some of the constraints of a relational DB are relaxed to provide scalability (see CAP theorem).
Also costs. If you have a low usage but multi-AZ redundant SQL setup, you will be paying for a minimum of 2-3 servers running 24/7; and for your 1 TPS website that's not really efficient to be paying so much. Managed NoSQL like Dynamo means you can pay a few cents instead of hundreds per month for the same setup.
@@azeeztaiwo2802 Yes. That's how they are able to achieve massive scale. HBase, DynamoDB, Cassandra etc. They have been fundamentally re-designed from the ground up to scale horizontally for writes as well as reads.
your videos are incredible. I am from another background (electronic engineering) and I am trying to move into the cloud computing field. So I find your videos really useful. Thanks!
Thank you so much Andres! I'm glad you find these helpful and good luck on your studies! If you have an idea for a topic please feel free to suggest it :)
missing out one important scenario .. transaction actions where integrity and atomic writes are key.. but rest of the video was quite good to understand thanks!
My experience is that NOSQL can also fit you if the data models is small and the primary key is natural. It is easy to change the data structure or add new attributes.
2:22 Relation ≠ Relationship. "Relation" in relational databases refers to the concept of finitary relations in mathematics. In mathematics, a relation is a subset of the Cartesian product of multiiple sets. In database world this translates to a table. So, Relation = Table.
Very good, thanks a lot. However I am not sure to understand how SQL can be better when access patterns are not well defined ? To me SQL is to used when data model and schema is strictly defined, when it is predictable and not going to change a lot ...
Access pattern means the way you query the data. If you only want to get the data according to its primary key, then it is well defined. If you want to get all the records with some properties(age>30, salary>10000,...etc), then it is not well defined. I think 'data model' you mentioned in your comment means the properties(age, salary, name...).
On point and informational. I come mainly from SQL world and have questions, 1. Can we have relations like SQL in nosql? Table/entity Relation etc. If so, are joins available? 2. If it's a document based, how do i segregate data and identify on code level?
Hi Zameer. Regarding #1 - This is implementation dependent. For example, in DynamoDB, you cannot perform joins, but you CAN perform transactions that retrieve values from multiple different tables at once. This is kind of a pseudo-join but not quite identical to the traditional SQL join. Regarding #2 - I don't really understand your question - perhaps you can re-phrase?
Thank you so much for explaining these two topics so well and concise. I now have a much clearer understanding of how to distinguish between DynamoDB and Aurora when it comes to my AWS studies. I'm just starting out in AWS cloud but your video has certainly given me a better understanding of databases. I appreciate you very much sir! Be well, Be safe and Cheers!
Your comparison of SQL to NoSQL is on point for key-value and document DBs, but it's way off-base when it comes to graph databases. Graph databases handle relationships *better* than SQL databases--it's what they are specifically designed to do; a graph can smoothly handle a query spanning many relationships which would bring a SQL database to its knees--and allow queries just as flexible as with SQL. (On the other hand, graphs don't scale horizontally any better or worse than SQL as far as I know.)
Great summary. Before SQL all databases were no-SQL, and when SQL to came along to solve the problems people had querying the data people really worried about how slow SQL databases were compared to non-SQL databases. But the convenience of being able to do ad-hoc queries joining data from different tables won people over and advances in CPU speed alleviated people's concerns about how slow SQL databases are compared with non-SQL databases. So I guess we've come full circle and now people are rediscovering pre-SQL database technology when they need the speed.
Great video dude. Can I respectively request you limit ads to the beginning and end of the video? Whatever you've got setup means I can't skip ahead to the sections I'm interested in without the video crashing. I've had to install an AdBlock in order to make it work.
Hi Paulus, Thanks for bringing this to my attention. I believe this is an issue with the TH-cam ad system itself. I will look into it and get back to you. Thanks
Thanks, a good video. I just wanted to add that mongodb in AWS world is not DocumentDB. It just offer you the mongo compatibility. Still, most of the mongo API's are not compatible with documentDB and it does take higher querying times when it comes to aggregation queries.
By NoSQL side you do not even have the necessity to use hashes as primaries keys. In Mongo you have the opportunity to use raw data as document key. Data as string or numbers or even indexes. So, you do not need to know the key to structure some query. By the way, this is an excellent video.
About the storage of NoSQL, when using hashing function, as an example, when the data increase and the storage and partitions become many and large, will there be any issues when users try to get data from partiion 1, or when updating will it cause delay? what are the side effects of having multiple thousands of partition in one NoSQL database? thank you in advance
Hi Yani, The beauty of NoSQL is that many partitions should have little if any performance impact by having many partitions. There is typically a routing component that is built into the engine's access layer that delegates the requests to the right partition - from there, its fetching the data like normal.
Thanks for the video. What I am not sure about is your statement of using SQL "When your access patterns are not defined". From what I understand, it is exactly the opposite. NoSQL is great if you don't know what your data look like exactly because it is generally schema-less whereas SQL require a strict schema??
Hi Saleh, What I meant was that when using NoSQL, it generally relies on the user to have a good handle on what he or she will be querying on. This is because a poor NoSQL schema design (especially with products such as DynamoDB) can severely affect an application's ability to scale. That being said, if a user is not sure what they will be querying on as their primary access pattern, it would make more sense to go with SQL because it is more flexible.
can you explain about required known primary key for NoSQL ? I though the DB can just auto assign one when not given unless you want to control which partition the data is going ?
NoSQL is not non-relational. In other words, NoSQL is not “No-SQL”. It is more of “not-only SQL”. Hope this video doesn’t propagate wrong info to others.
Access patterns are just various different ways the data will be queried for a particular type of application. Heres a link to a great talk about NoSQL by Rick Houlihan th-cam.com/video/HaEPXoXVf2k/w-d-xo.html. I would recommend watching the whole thing, but if you're only interested in exploring what access patterns are with examples, here is a timestamp where he explains what access patterns are th-cam.com/video/HaEPXoXVf2k/w-d-xo.html
While it is true that nosql shouldn't be used for small projects, surely there is still value in making a project that uses nosql if not purely for learning purposes?
The Read Replicas are handled and added from/by DBMS system or are handled from the application level ?? And Does Sharding(Application level sharding) helps to scale SQL databases horizontally ??
For SQL, what do you mean when you say "your access patterns aren't defined"? And also, when you talk of flexible queries, what do you mean, and why aren't queries in NoSQL not flexible?
SQL DBs are designed to support ad-hoc queries across multiple tables, thus you can access your data in very flexible ways and don't necessarily need to plan the way you'll access the data ahead of time. NoSQL DBs, on the other hand, (usually) don't allow that much flexibility when querying your data, so you usually design your data structure to specifically support some access pattern. The cost of the power you get with SQL is payed for in poor read performance and difficulties with horizontal scaling. As with anything, there are ways around these limitations.
@@ChumX100 "don't necessarily nee to plan the way you'll access the data ahead of time". Isn't it more complicated to change data schema when it comes to relational database? NoSQL is naturally schema-less and if you want to add more column you can just add it without breaking the data integrity.
@석상주 Yes, it is more difficult to change the schema in relational DBs, they are not as flexible as NoSQL DBs. But even if your schema does not support your current access patterns perfectly, you can usually get around it by leveraging the powerful query engine without needing to change your schema. With SQL you push complexity to your queries, whereas with NoSQL you usually work harder on getting your data in the right shape and then the queries are trivial and efficient.
what would you do if you needed relational data storage on a large project that needs to store lots of data, more data than each replica db can handle.
It depends on your the data structure, if you know the hirarchy of it you will have easy time to choose. no sql is fast because the stored data pattern is consistent.
Hi there, I think it is generally a good idea to start with SQL such as Postgres or MySQL. If you need extra performance that NoSQL databases support, you can always switch later. Hope this helps.
I still don’t understand why NoSQL is said to be ‘non relational ‘ Objects in nosql databases have foreign ids referencing other objects. What am I not understanding?
Hi there, You are correct that NoSQL can have foreign ids referencing other objects. The important bit is that the the entities corresponding to these objects is not stored within the same database. This limits relational style queries where users can pull, in one query, all the rows of one table and the objects that correspond to the foreign key ids. in relational DBMS systems, it would be possible to do so. But in NoSQL, you would need to make multiple independent queries. Hope this clears it up
@@BeABetterDev Well thanks for responding to _my_ query haha ; ) I'm still a little confused as to why this distinction is always made as if its an insurmountable problem with NoSQL? There are libraries like Mongoose which allow you to easily pool multiple resources with one request. Is the distinction made more out of being a performance issue? I built a backend using Mongoose and a MongoDB database and built middleware that uses Mongoose's 'populate'. Here's an example of a query: Query string: /vendors?business_name=Jim's Cookies&select=business_name&populate=products&popselect=name&nest=images&nestselect=format,url Results: vendor : business_name: "Jims' Cookies", products: [{ name: 'Butter Pecan', images: [ {'url': 'www.as;fwsj;lsf', format: jpg}...] }, ...]
I watched this entire video and I still have no idea why I would want to use NoSQL. What good is a database that isn't relational? And if you need to know the key for each item then where are you supposed to store the key? In an SQL database?! It sounds completely useless.
I watched several clips with that subject. They all explain the way SQLDBs store information with a tangible example (customer - order - item). They show the way how information is stored in tables, explain what a key is and so on. But when it comes to explain how Non SQLDBS work, they remain abstract, do not show any example and switch to advantages and disadvantages or use cases at once. Shit. :-)
@@BeABetterDev I am sorry, but in fact, it wasn't. I was interested *how* information is stored and accessed to in comparison to NonSQL DB and I did not find and answer. Nearly all clips I found up to now when explaining SQL show tables and entries and columns with the PK, but when they switch to NonSQL they say: 'Well, NonSQL DB do that differently and therefore they are much more performant and suitable for this and that. Even facebook uses it, so it must be great. Thanks for watching'. You as well start to chat about the different types and the infrastructure instead of explainig the core question. And I am as clever as before. :-)
The' when to use what' section was really helpful and just when I thought it couldn't get any better, you included a 'how to pick' section. Good job! Thank you.
Thanks so much Elena! Glad you found that last bit useful :)
No clutters only content. Well articulated and explained. Thanks.
Glad you enjoyed it!
Finally!!! I've been looking for a straight to the point video on relational vs non-relational database and this video explains it succinctly and even more. Thanks a bunch
You're very welcome!
Looked at another walkthrough, had no Idea what NoSql was afterwards. Looks at this video with pictures and examples, gets it in 2 minutes.
Glad you found it helpful!
I had to login to youtube just to subscribe to your videos. I really like them, easy to follow and very relevant. Thank you for these wonderful videos.
Thank you so much pravin, I really enjoy the the kind words of support. I will continue making videos just like this one!
One of the best explanation for SQL vs NoSQL on TH-cam！
Thanks so much Hunter glad you enjoyed
this channel is a goldmine good lord
Thank you Nakapeesh!
Finally I find what I looked for. It is quick and simple and clear explanation and I looked for this short and complete answer it for my aws interview. Thanks thousands
Glad it helped!
Great summary. The main motivation for development of non-relational databases is around scaling. A relational database scales out reasonably well for reads (there is a clue in the name "Read Replicas"), but there is still a single master, hence a bottleneck for writes. The design of KV stores was largely to get around this problem. Some of the constraints of a relational DB are relaxed to provide scalability (see CAP theorem).
Very good point justin. I would pin this comment if I could as I forgot to mention it in the video!
Also costs. If you have a low usage but multi-AZ redundant SQL setup, you will be paying for a minimum of 2-3 servers running 24/7; and for your 1 TPS website that's not really efficient to be paying so much. Managed NoSQL like Dynamo means you can pay a few cents instead of hundreds per month for the same setup.
But are you suggesting you have multiple write nodes for nosql ?
@@azeeztaiwo2802 Yes. That's how they are able to achieve massive scale. HBase, DynamoDB, Cassandra etc. They have been fundamentally re-designed from the ground up to scale horizontally for writes as well as reads.
@@princeofgonville So does it mean that NoSql databases are designed as a distributed system or are distributed in nature?
thank you so much for this video, I have been struggling to understand what NoSQL is but this video really helped
You're very welcome!
The best explanation i found on internet
You really clearly explained in a lucid way!
Thank you very much Nagato!
your videos are incredible. I am from another background (electronic engineering) and I am trying to move into the cloud computing field. So I find your videos really useful. Thanks!
Thank you so much Andres! I'm glad you find these helpful and good luck on your studies! If you have an idea for a topic please feel free to suggest it :)
This is by far the best explanation I have come across🙌Your channel is a gem
Thanks so much Yash!
Great example! Information was presented very clear and easy to understand.
missing out one important scenario .. transaction actions where integrity and atomic writes are key.. but rest of the video was quite good to understand thanks!
Great video! Flexible access patterns is definitely a big Pro for choosing a database like postgres.
Totally agree!
My experience is that NOSQL can also fit you if the data models is small and the primary key is natural. It is easy to change the data structure or add new attributes.
Very helpful. Thank you for your time creating this
You're very welcome Hari! Glad you enjoyed.
2:22 Relation ≠ Relationship. "Relation" in relational databases refers to the concept of finitary relations in mathematics. In mathematics, a relation is a subset of the Cartesian product of multiiple sets. In database world this translates to a table. So, Relation = Table.
i think this is the best summary
Thanks so much Hakan!
The BEST explanation! Thanks!
Glad it was helpful!
Very good, thanks a lot. However I am not sure to understand how SQL can be better when access patterns are not well defined ? To me SQL is to used when data model and schema is strictly defined, when it is predictable and not going to change a lot ...
Access pattern means the way you query the data. If you only want to get the data according to its primary key, then it is well defined. If you want to get all the records with some properties(age>30, salary>10000,...etc), then it is not well defined. I think 'data model' you mentioned in your comment means the properties(age, salary, name...).
In general, NoSQL can only be queried by primary key. No filter or condition, you have to provide the exact key value.
Agreed. No wild data.
NoSQL is best when the data is wild and fast moving. Especially for large scale data.
@@liuculiu8366 now i get it, it really confused me when it was just casually stated in the video
This was really helpful and well explained. Thanks a lot!
You're very welcome!
Amazing explanation, thanks for your efforts!
On point and informational.
I come mainly from SQL world and have questions,
1. Can we have relations like SQL in nosql? Table/entity Relation etc. If so, are joins available?
2. If it's a document based, how do i segregate data and identify on code level?
Hi Zameer.
Regarding #1 - This is implementation dependent. For example, in DynamoDB, you cannot perform joins, but you CAN perform transactions that retrieve values from multiple different tables at once. This is kind of a pseudo-join but not quite identical to the traditional SQL join.
Regarding #2 - I don't really understand your question - perhaps you can re-phrase?
Thank you so much for explaining these two topics so well and concise. I now have a much clearer understanding of how to distinguish between DynamoDB and Aurora when it comes to my AWS studies. I'm just starting out in AWS cloud but your video has certainly given me a better understanding of databases. I appreciate you very much sir! Be well, Be safe and Cheers!
Your comparison of SQL to NoSQL is on point for key-value and document DBs, but it's way off-base when it comes to graph databases. Graph databases handle relationships *better* than SQL databases--it's what they are specifically designed to do; a graph can smoothly handle a query spanning many relationships which would bring a SQL database to its knees--and allow queries just as flexible as with SQL. (On the other hand, graphs don't scale horizontally any better or worse than SQL as far as I know.)
One important point missed out is SQL provides ACID properties and transactional guarantees, NoSQL doesn't.
This was a really bad omission of mine. Thanks for pointing this out Shubham!
Excellent to the point content sir. Thanks for the time you spent composing it.
You are very welcome! Glad you enjoyed.
I'm planning to learn more stuff abt back end development. Thanks for this video!!
You're very welcome Kelzeu!
Good simple explanation!
Thanks sansce!
Thanks! Very clear explanation.
You're very welcome!
This was amazing,thank you so much!
Glad you enjoyed it!
Wow, that's well explained!
Thanks Marcel! Glad you enjoyed.
Great video!! A quick and to the point explanation.
Thanks Dinkar! Glad you found it helpful :)
Great explanation, thanks
note that with Vitess, you can scale SQL (what they call NewSQL)
Great summary.
Before SQL all databases were no-SQL, and when SQL to came along to solve the problems people had querying the data people really worried about how slow SQL databases were compared to non-SQL databases. But the convenience of being able to do ad-hoc queries joining data from different tables won people over and advances in CPU speed alleviated people's concerns about how slow SQL databases are compared with non-SQL databases. So I guess we've come full circle and now people are rediscovering pre-SQL database technology when they need the speed.
Great video dude.
Can I respectively request you limit ads to the beginning and end of the video?
Whatever you've got setup means I can't skip ahead to the sections I'm interested in without the video crashing. I've had to install an AdBlock in order to make it work.
Hi Paulus,
Thanks for bringing this to my attention. I believe this is an issue with the TH-cam ad system itself. I will look into it and get back to you.
Thanks
Great summary.
Thanks Sujin!
Great Summary, well done!
Thanks Farzad!
Great to the point wholesome content! Thank you.
Thank you !
8:50 i'd rather say its beneficial to not be tied to a specific vendor
I.e. I can change Postgres to MySQL quite easily
very useful and well explained. Thanks for it. i was looking for good content. this is it
Thank you Anada! Glad you enjoyed and welcome to the channel!
Hi, thank you for video.
You are so welcome!
Great video man
Thank you!
Awesome review!
Thanks, a good video. I just wanted to add that mongodb in AWS world is not DocumentDB. It just offer you the mongo compatibility. Still, most of the mongo API's are not compatible with documentDB and it does take higher querying times when it comes to aggregation queries.
nice video, i was in a hurry
By NoSQL side you do not even have the necessity to use hashes as primaries keys. In Mongo you have the opportunity to use raw data as document key. Data as string or numbers or even indexes. So, you do not need to know the key to structure some query.
By the way, this is an excellent video.
Hi Jesus,
Thanks for sharing your thoughts on Mongo!
About the storage of NoSQL, when using hashing function, as an example, when the data increase and the storage and partitions become many and large, will there be any issues when users try to get data from partiion 1, or when updating will it cause delay? what are the side effects of having multiple thousands of partition in one NoSQL database? thank you in advance
Hi Yani,
The beauty of NoSQL is that many partitions should have little if any performance impact by having many partitions. There is typically a routing component that is built into the engine's access layer that delegates the requests to the right partition - from there, its fetching the data like normal.
very good summary
Thanks ahly!
Great video, Thanks!
You're very welcome!
great vídeo, thanks
You're very welcome Paulo!
Thanks for the video. What I am not sure about is your statement of using SQL "When your access patterns are not defined". From what I understand, it is exactly the opposite. NoSQL is great if you don't know what your data look like exactly because it is generally schema-less whereas SQL require a strict schema??
Hi Saleh,
What I meant was that when using NoSQL, it generally relies on the user to have a good handle on what he or she will be querying on. This is because a poor NoSQL schema design (especially with products such as DynamoDB) can severely affect an application's ability to scale.
That being said, if a user is not sure what they will be querying on as their primary access pattern, it would make more sense to go with SQL because it is more flexible.
thank you
You're welcome!
can you explain about required known primary key for NoSQL ? I though the DB can just auto assign one when not given unless you want to control which partition the data is going ?
it was so helpful Thank you
Sir, could you please elaborate what do you mean by "unknown access patterns in SQL"?
Nice video! Thank you.
Glad you liked it!
NoSQL is not non-relational. In other words, NoSQL is not “No-SQL”. It is more of “not-only SQL”. Hope this video doesn’t propagate wrong info to others.
Thank you!
You're very welcome Daniel
what does it mean in term of "unknown access pattern"? can you guys give me an example?
Access patterns are just various different ways the data will be queried for a particular type of application.
Heres a link to a great talk about NoSQL by Rick Houlihan th-cam.com/video/HaEPXoXVf2k/w-d-xo.html. I would recommend watching the whole thing, but if you're only interested in exploring what access patterns are with examples, here is a timestamp where he explains what access patterns are th-cam.com/video/HaEPXoXVf2k/w-d-xo.html
thanks for sharing!
You're very welcome Muhammad!
Fantastic video
Thank you, Akshay!
Great video!
Thanks Ben! Glad you enjoyed.
Thanks a lot ❤️
I want to store news articles' text and allow for efficient/dynamic text search. SQL seems like the go to?
I would actually look at a more specialized nosql database like elasticsearch/opensearch.
Good video
Thank you very much!
While it is true that nosql shouldn't be used for small projects, surely there is still value in making a project that uses nosql if not purely for learning purposes?
The Read Replicas are handled and added from/by DBMS system or are handled from the application level ?? And Does Sharding(Application level sharding) helps to scale SQL databases horizontally ??
short and sweet
Thank you so much!
For SQL, what do you mean when you say "your access patterns aren't defined"? And also, when you talk of flexible queries, what do you mean, and why aren't queries in NoSQL not flexible?
SQL DBs are designed to support ad-hoc queries across multiple tables, thus you can access your data in very flexible ways and don't necessarily need to plan the way you'll access the data ahead of time.
NoSQL DBs, on the other hand, (usually) don't allow that much flexibility when querying your data, so you usually design your data structure to specifically support some access pattern.
The cost of the power you get with SQL is payed for in poor read performance and difficulties with horizontal scaling. As with anything, there are ways around these limitations.
@@ChumX100 "don't necessarily nee to plan the way you'll access the data ahead of time". Isn't it more complicated to change data schema when it comes to relational database? NoSQL is naturally schema-less and if you want to add more column you can just add it without breaking the data integrity.
@석상주 Yes, it is more difficult to change the schema in relational DBs, they are not as flexible as NoSQL DBs. But even if your schema does not support your current access patterns perfectly, you can usually get around it by leveraging the powerful query engine without needing to change your schema. With SQL you push complexity to your queries, whereas with NoSQL you usually work harder on getting your data in the right shape and then the queries are trivial and efficient.
You my friend, get a subscriber for this video.
Thanks Faisal, and welcome to the channel!
what would you do if you needed relational data storage on a large project that needs to store lots of data, more data than each replica db can handle.
Thanks a lot!
You're very welcome Zeal!
The correct naming It's relational and non relational DBs, not SQL and NoSQL.
مبدع استمر
Which one would you recommend for an e-learning website?
I think Udemy is a popular choice. Coursera also comes to mind. Cheers.
Thanks!
Well-Done
So how do you define a large project? 1TB data? or 100TB data?
It depends on your the data structure, if you know the hirarchy of it you will have easy time to choose. no sql is fast because the stored data pattern is consistent.
what if f(x) equals a previous hash? what happens? will it create a new node on the same partition? -> 6:32
For E-Commerce App or Website which Database should i use
Hi there, I think it is generally a good idea to start with SQL such as Postgres or MySQL. If you need extra performance that NoSQL databases support, you can always switch later. Hope this helps.
Make sure you put your database behind an interface though so that you can easily change later!
@@BeABetterDev behind the interface means what?
I took my no sql course 2 years ago, O didn't even know Sql existed
I still don’t understand why NoSQL is said to be ‘non relational ‘ Objects in nosql databases have foreign ids referencing other objects. What am I not understanding?
Hi there,
You are correct that NoSQL can have foreign ids referencing other objects. The important bit is that the the entities corresponding to these objects is not stored within the same database. This limits relational style queries where users can pull, in one query, all the rows of one table and the objects that correspond to the foreign key ids. in relational DBMS systems, it would be possible to do so. But in NoSQL, you would need to make multiple independent queries.
Hope this clears it up
@@BeABetterDev Well thanks for responding to _my_ query haha ; ) I'm still a little confused as to why this distinction is always made as if its an insurmountable problem with NoSQL? There are libraries like Mongoose which allow you to easily pool multiple resources with one request. Is the distinction made more out of being a performance issue?
I built a backend using Mongoose and a MongoDB database and built middleware that uses Mongoose's 'populate'. Here's an example of a query:
Query string: /vendors?business_name=Jim's Cookies&select=business_name&populate=products&popselect=name&nest=images&nestselect=format,url
Results: vendor : business_name: "Jims' Cookies", products: [{ name: 'Butter Pecan', images: [ {'url': 'www.as;fwsj;lsf', format: jpg}...] }, ...]
The high performance part was not enough. High performance of what? Read, Write? what?
Brilliant
I watched this entire video and I still have no idea why I would want to use NoSQL. What good is a database that isn't relational? And if you need to know the key for each item then where are you supposed to store the key? In an SQL database?! It sounds completely useless.
You forgot Schema with RDMS
SQL is inevitable now !
"In a SQL table you must have a primary key". You lost me here.
There are projects who require both sql and nosql
🔥🧨
I thought you use NoSql when your a access pattern is not predefined??? Kinda of confusing
Same, even the flexible one is supposed to be NoSQL not the other one.
I watched several clips with that subject. They all explain the way SQLDBs store information with a tangible example (customer - order - item). They show the way how information is stored in tables, explain what a key is and so on. But when it comes to explain how Non SQLDBS work, they remain abstract, do not show any example and switch to advantages and disadvantages or use cases at once. Shit. :-)
Hi Michael, I think this comment is a compliment - if so, thank you! If not, I appreciate feedback in how I can improve. Cheers.
@@BeABetterDev I am sorry, but in fact, it wasn't. I was interested *how* information is stored and accessed to in comparison to NonSQL DB and I did not find and answer. Nearly all clips I found up to now when explaining SQL show tables and entries and columns with the PK, but when they switch to NonSQL they say: 'Well, NonSQL DB do that differently and therefore they are much more performant and suitable for this and that. Even facebook uses it, so it must be great. Thanks for watching'. You as well start to chat about the different types and the infrastructure instead of explainig the core question. And I am as clever as before. :-)
Why do people get so triggered when you prefer something DynamoDB?
Sad mongodb has no auto increment.
atlas mongo over documentDB. documentDB is always behind when it comes to features.