I like the video, just about the conclusion about the choice between relational vs non relational db, I think it shouldn't rely on whether there are relations between the data or not, but rather on the need to denormalize vs normalize the data. Sometimes we have data that have relations, but we want to denormalize it, because updates and deletes may be rare that we can afford for these operations to take some time, but we want fast reads. I think the choice, of whether to normalize vs denormalize, will depend on the SLAs we want for each operation (read, update, delete, write) and how the queries will look like (we want to optimize reads, we want that updates), if the choice is to normalize, then the DB is better be relational to have the relations, foreign keys and the ability to join handled for us. But on the other hand, if we decide to denormalise, we can sometimes find relational DBs that perform better based on the usecase and on how other parts are implemented (Indexes, ...)
I like to think of SQL as the starting point. When we want to scale, we'll have to compromise on certain functionalities of SQL. We can start by dropping foreign key constraints, partitioning tables, sharding based on certain keys and somewhere in between NoSQL will start to make sense to meet the SLAs
Hi Jordan, great video as always! This might be a silly question. In the Train station example using SQL, is it possible to store both tables in the same database? This way we can avoid 2PC and also network calls.
I like the video, just about the conclusion about the choice between relational vs non relational db, I think it shouldn't rely on whether there are relations between the data or not, but rather on the need to denormalize vs normalize the data. Sometimes we have data that have relations, but we want to denormalize it, because updates and deletes may be rare that we can afford for these operations to take some time, but we want fast reads.
I think the choice, of whether to normalize vs denormalize, will depend on the SLAs we want for each operation (read, update, delete, write) and how the queries will look like (we want to optimize reads, we want that updates), if the choice is to normalize, then the DB is better be relational to have the relations, foreign keys and the ability to join handled for us. But on the other hand, if we decide to denormalise, we can sometimes find relational DBs that perform better based on the usecase and on how other parts are implemented (Indexes, ...)
I think that's a very good point, thanks for mentioning it!
i appreciated the your mom jokes probably way more than i should have
So does she
@@jordanhasnolife5163 lmao, ok this guy is pretty funny
I laughed hard at the decommissioned mom station. Really caught me off guard there
I like to think of SQL as the starting point. When we want to scale, we'll have to compromise on certain functionalities of SQL. We can start by dropping foreign key constraints, partitioning tables, sharding based on certain keys and somewhere in between NoSQL will start to make sense to meet the SLAs
I think that's a really cool way of putting it! Thanks for sharing!
Do a Chiraq vlog!! Lots of transactions each day, records constantly being created and destroyed and an ever-changing many to many relationship
Haha perhaps soon :)
Hi Jordan, great video as always! This might be a silly question. In the Train station example using SQL, is it possible to store both tables in the same database? This way we can avoid 2PC and also network calls.
Yep - just keep in mind that as things scale this isn't always possible.
What books do you read for system design?
What are your sources?
Please tell
Too many to count since I've watched a lot of random CZcams videos, but mainly DDIA
Thanks
420 BLAZE IT BRO
Where u working now
In trading but afraid to say exactly where for fear of getting fired
@@jordanhasnolife5163 Chicago, so maybe IMC