The schema shown is just an example to show the limitations of the relational model. Point is, NoSQL databases allow us to design around query patterns. The same logical data could result in very different schemas depending on the requirements or which database we choose. If you want to learn about non-relational schema design, you might want to look at our course on interviewpen.com :)
@@interviewpen True, but I think I speak for most of us when I say we were expecting to see how you would design the NoSQL data model to solve the issues you mentioned, with regards to querying products in an order and getting the number of times a product appears across all orders.
Good stuff! However, what is also important apart from schema, that relational database has relatively slow writes/updates because of their index structure (B-tree) and storage mechanisms. Apache Cassandra, afaik, has LSM tree and mem tables. MongoDB has async I/O journaling and also has LSM tree (or does it?) in addition to B-tree. I, personally, dont like any relational DB, but "right tool for the right job" :)
@@charliebitmyfinger7124 NoSQL database are also acid compliant. It depends on what guarantees they provide, as every engine provides different guarantees.
Relational is more often than not the right tool for the job in hand. Use cases for nosql are very narrow in real world applications. It's good if you know your exact requirements and it fits the purpose. Most under development projects don't know exact requirements and they change with time, nosql will bite you for eternity
Yep--companies that need to query massive amounts of transactional data typically use NoSQL databases for flexibility when distributing data across a large cluster.
Postgresql offers the same power as MongoDB when it comes to json, so there's no sense to choose MongoDB even if you want to store your data in denormalized form.
From my understanding, postgres doesn’t have the same ability to select or filter on json fields. But regardless, using a solution that was designed from the ground up for this use case will generally result in a better experience. Thanks for the insight!
@@interviewpen Postgres can quite nicely filter/search/index the json fields; however, this only does not make it an ideal candidate to choose over MongoDB.
I think you missed a huge aspect about when you to choose between SQL vs NoSQL. At the end of the day, its more about picking the right tool for the job, and less about the scale of the data. If you need ACID transactions, use SQL. If you're okay with eventual consistency then NoSQL might be easier. The scale of your data is just one minor aspect you need to consider when building a system. I'd argue you can scale both types of DBs just as much as each other but it'll all come down to what kind of trade offs you're willing to make. Its not uncommon to have a combination of both NoSQL and SQL DBs, they are not mutually exclusive.
Is it possible to just explain it in really simple way? After 6 minutes I still doesn't understand about what are you talking about. For the what reason you give this examples for SQL scaling problems for the whole video??? Redicilous...
I'm i missing something or he didn't design the model in nosql ?
Exactly my thought as well..
The schema shown is just an example to show the limitations of the relational model. Point is, NoSQL databases allow us to design around query patterns. The same logical data could result in very different schemas depending on the requirements or which database we choose. If you want to learn about non-relational schema design, you might want to look at our course on interviewpen.com :)
@@interviewpen True, but I think I speak for most of us when I say we were expecting to see how you would design the NoSQL data model to solve the issues you mentioned, with regards to querying products in an order and getting the number of times a product appears across all orders.
Can I ask what should a NoSQL database table schema look like?
Should it looks like 0:05 ?
Good stuff!
However, what is also important apart from schema, that relational database has relatively slow writes/updates because of their index structure (B-tree) and storage mechanisms.
Apache Cassandra, afaik, has LSM tree and mem tables.
MongoDB has async I/O journaling and also has LSM tree (or does it?) in addition to B-tree.
I, personally, dont like any relational DB, but "right tool for the right job" :)
Relational databases are also acid compliant and are by far the most reliable types of databases.
@@charliebitmyfinger7124 NoSQL database are also acid compliant. It depends on what guarantees they provide, as every engine provides different guarantees.
Really great insights, thanks!
Relational is more often than not the right tool for the job in hand. Use cases for nosql are very narrow in real world applications. It's good if you know your exact requirements and it fits the purpose. Most under development projects don't know exact requirements and they change with time, nosql will bite you for eternity
do most large scale companies use nosql then in favor of ease of storing and accessing data?
Yep--companies that need to query massive amounts of transactional data typically use NoSQL databases for flexibility when distributing data across a large cluster.
nitpick. We lost quantity when we went from model to table on order_product table
Postgresql offers the same power as MongoDB when it comes to json, so there's no sense to choose MongoDB even if you want to store your data in denormalized form.
@codingwithjamal nope. Postgres stores json as jsonb and it is blazingly fast.
From my understanding, postgres doesn’t have the same ability to select or filter on json fields. But regardless, using a solution that was designed from the ground up for this use case will generally result in a better experience. Thanks for the insight!
@@interviewpen Postgres can quite nicely filter/search/index the json fields; however, this only does not make it an ideal candidate to choose over MongoDB.
I think you missed a huge aspect about when you to choose between SQL vs NoSQL. At the end of the day, its more about picking the right tool for the job, and less about the scale of the data. If you need ACID transactions, use SQL. If you're okay with eventual consistency then NoSQL might be easier. The scale of your data is just one minor aspect you need to consider when building a system. I'd argue you can scale both types of DBs just as much as each other but it'll all come down to what kind of trade offs you're willing to make. Its not uncommon to have a combination of both NoSQL and SQL DBs, they are not mutually exclusive.
Is it possible to just explain it in really simple way? After 6 minutes I still doesn't understand about what are you talking about. For the what reason you give this examples for SQL scaling problems for the whole video??? Redicilous...
this is gold
Thanks for watching!