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 appreciated the your mom jokes probably way more than i should have
So does she
@@jordanhasnolife5163 lmao, ok this guy is pretty funny
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 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!
I laughed hard at the decommissioned mom station. Really caught me off guard there
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 RUclips videos, but mainly DDIA
Where u working now
In trading but afraid to say exactly where for fear of getting fired
@@jordanhasnolife5163 Chicago, so maybe IMC
420 BLAZE IT BRO
Thanks