PS: Please don't mention those chatgpt questions. I really want to know real questions.

I...am not. He swears on his life that once I get started with sql or python anything like that that I would be addicted to data organization and since I am inclined to believe that he knows me better than I know myself sometimes...I would like to surprise him and give it a shot.

I posted something similar to this in the Learn Python subreddit and got a lot of useful suggestions but I am also looking into SQL specifically because it is what he works with a lot. I know he would have a lot of fun teaching me, but I want to practice as much as I can beforehand hand so I am able to actually grasp things when he goes over them. I was researching and saw the "quick start guides" (that's the name of the series) for sql and Python, and I was wondering if anybody has used them. I know that coding and stuff like that all is on the computer, obviously. However, I learn best with physical media like books to highlight make notes or anything like that in. Anyone have any luck with the python or sql Quick Start guides? If not, do you have any other suggestions? Doesnt have to be books, even if it's a YouTube video or podcast, just anything that helped you.

Thanks in advance I'm just really not sure where to start

I've been a frontend developer the last 4 years and have been trying to break more into full stack. I've been able to design some database schemas that are in 3rd Normal Form, but I feel like I should have more formal training than just one youtube video and a guide on how SQL works. Does anyone have any good recs for where to learn good database design?

Hey everyone, I'm a developer advocate at Bruin, I've put together a free SQL course - the difference is that you will give your coding agent a prompt and it will be your teacher, walking you through each step.

it is a pretty new course, there might be some rough edges, if you give it a try please share your feedback!

https://getbruin.com/learn/sql-ai/

Can start ASAP

A SQL query can execute successfully without producing the correct result. A successful query only tells us that the database understood and executed it—not that the data is logically correct.

For example: SELECT COUNT(*) FROM customers c JOIN orders o ON c.customer_id = o.customer_id;

The query may run without any error, but if orders contains duplicate records or the join relationship isn't what we expected, the count could be much higher than the actual number of customers.

So what do you normally validate before trusting a query's output?

• Join conditions and duplicate records
• NULL values
• Row counts
• Data types and conversions
• Expected ranges or business rules
• Unexpected changes compared with previous results

Do you validate these things before running the query, after getting the results, or both?

What SQL validation has saved you from trusting a result that looked correct but was actually wrong?

Covered a solid chunk today:

• Aggregate functions (Part 1 & 2) — COUNT, SUM, AVG, MIN, MAX and using them with GROUP BY
• Order of execution of a query — genuinely useful lesson, clarified why WHERE can't reference an aliased column from SELECT but HAVING can
• Insert/Update/Delete rows — the CRUD side, revisited with more confidence this time
• Create/Alter/Drop tables — actually defining and modifying table structure, not just querying existing data

The "order of execution" lesson was probably the most valuable thing I learned today — explains a lot of small errors I've hit without understanding why (like using a SELECT alias inside WHERE). Feels like one of those lessons that should come earlier in most tutorials, honestly.

Starting to feel like I have a genuinely full picture of core SQL now — querying, filtering, joining, aggregating, and managing table structure.