"Tip 18 : Before you run Update or Delete statement run it as Select statement first" ooh man, I learned this tip the hard way. Again, This is an amazing videos, thanks a lot for sharing these tips
dbml is pretty great for documentation purposes. I much prefer it over some random ERD editor. Tip 17 really depends on what it is. For some things there is really no point. Tip 19 also really depends. When done correctly, denormalization can help a lot with query performance and resource optimization. But this is mainly very big DBs and high load situations.
Watching your channel, I realize how many mistakes I made in my old web projects. If I encounter SQL again, I will be many times smarter. Thank you so much! P. S. Only a handful of subscribers for such a useful channel. That's not right.
Isn't a CTE though just some sugar syntax for a temp table - which you can also name what you want. Maybe under the hood it has some more efficiencies but I think a temp table may offer some slight additional freedoms also (you can do all sorts of work on it before calling it in a later join, and even have that work interspersed with other work first also. I think CTEs look cleaner and keep the code tidy but I tend to use temp tables and just go wild (Lol).
It's like syntactic sugar for a subquery, rather than a temp table. It's similar to a temp table however there is no database object created. As you mentioned, a temp table has some additional freedoms and you can do more work with them before the main query.
I'm not the primary back-end dev at my job, but my colleague who has been there for over a decade still writes his SQL statements manually in the terminal every time, especially in production, and I get mini heart attacks every time I see him write DELETE or UPDATE. I don't want to pretend like I know more than him, but I don't think that's a good idea. I have pointed out to him more than once a typo he's close to making.
I don't agree with 'Don't be afraid of joins', it is a performance hit both for CPU and IO. You should avoid them if it makes sense, and use them if they are neccesary. It depends on the project, the budget, the type of sql software. For example if you are using sqlite single node performance can be important.
Good point. I feel it's more important to design your database so it's an effective design, such as not repeating data and making maintenance easy. If you need to improve performance, there are things you can do to write queries to avoid joins (materialised views, temp tables, and so on).
Want to easily remember the SQL commands for your database? Get my free SQL Cheat Sheets here: www.databasestar.com/get-sql-cheat-sheets/?
"Tip 18 : Before you run Update or Delete statement run it as Select statement first"
ooh man, I learned this tip the hard way.
Again, This is an amazing videos, thanks a lot for sharing these tips
Thanks a lot!
Screwing up a production database is the graduation ceremony 😅
Your channel literally changed my life, I am backend I learned sql and database but I found your channel amazing
Thanks a million 😊
Wow thanks for the kind words. I’m glad you like the channel 😊
Thx dude, this is video is pure gold!
Glad you liked it!
Great job, bro! Thanks!!
You're welcome!
dbml is pretty great for documentation purposes. I much prefer it over some random ERD editor.
Tip 17 really depends on what it is. For some things there is really no point.
Tip 19 also really depends. When done correctly, denormalization can help a lot with query performance and resource optimization. But this is mainly very big DBs and high load situations.
Thanks for sharing!
Watching your channel, I realize how many mistakes I made in my old web projects. If I encounter SQL again, I will be many times smarter. Thank you so much!
P. S. Only a handful of subscribers for such a useful channel. That's not right.
You're welcome! I also wish I knew a lot of these things early in my career.
Nice tips. Thanks for sharing. I have subscribed.
Thanks for the sub!
Isn't a CTE though just some sugar syntax for a temp table - which you can also name what you want. Maybe under the hood it has some more efficiencies but I think a temp table may offer some slight additional freedoms also (you can do all sorts of work on it before calling it in a later join, and even have that work interspersed with other work first also. I think CTEs look cleaner and keep the code tidy but I tend to use temp tables and just go wild (Lol).
It's like syntactic sugar for a subquery, rather than a temp table. It's similar to a temp table however there is no database object created. As you mentioned, a temp table has some additional freedoms and you can do more work with them before the main query.
THANKS FOR THIS RELLY HELPFUL
Glad it helped!
Excellent tips. Thank you!
Glad it was helpful!
Great advice, thanks Ben!
No worries!
Fantastic Advice!
Glad it was helpful!
Thanks for the tips!
You're welcome!
Excellent. Thank you.
You’re welcome!
I especially loved tips ## 17, 18
Thanks!
I'm not the primary back-end dev at my job, but my colleague who has been there for over a decade still writes his SQL statements manually in the terminal every time, especially in production, and I get mini heart attacks every time I see him write DELETE or UPDATE. I don't want to pretend like I know more than him, but I don't think that's a good idea. I have pointed out to him more than once a typo he's close to making.
Wow that’s risky! Not surprising though, we can all get stuck in our ways sometimes.
Thanks for sharing!
Thanks Ben
No problem!
Tip number 18, I learned the hard way 5 years ago 😢
Oh yeah this tip can definitely be learned the hard way (I've done it too)
THANK YOU BIRO FROM ETHIOPIA ADDIS ABABA
You’re welcome!
I don't agree with 'Don't be afraid of joins', it is a performance hit both for CPU and IO. You should avoid them if it makes sense, and use them if they are neccesary. It depends on the project, the budget, the type of sql software. For example if you are using sqlite single node performance can be important.
Good point. I feel it's more important to design your database so it's an effective design, such as not repeating data and making maintenance easy. If you need to improve performance, there are things you can do to write queries to avoid joins (materialised views, temp tables, and so on).
Excellent. Thank you.
You are welcome!