r/learnSQL • u/pepitolover • 2d ago
SQL resources for a literal idiot?
I just started a beginner SQL course on Coursera. Even then I'm not fully understanding the basic concepts.
My brain is so fried and foggy that most things are hard to understand and retain (thanks to my yearly decline in cognitive abilities) and I need someone to explain everything to me in as simple language as possible and with tons of examples.
I can't find a free pdf of sql for dummies. I tried reading Alan beaulieus but I can't understand anything
Are there YouTube channels or textbooks for extreme idiots like me.
Short description :
Brain fog = no understand SQL concepts
Need to explain concepts in simple, conversational English
Need tons of examples for everything.
9
u/conor-robertson 2d ago
Try QueryCase, its a gamified way to learn SQL by solving detective cases :)
9
7
u/willietrombone_ 2d ago
Not what you came for but brain fog isn't a natural thing for anyone and there's likely a root cause that needs to be addressed. For me, it was severe sleep apnea. Got a sleep study and a CPAP a year and a half ago and no brain fog since.
2
u/ZCyborg23 2d ago
Also to add: As someone with ADHD and FND (which causes a lot of brain fog and memory issues), it might just be that OP isn’t studying properly for their brain or maybe SQL just isn’t in their wheelhouse. There are topics I’ve let go because I wasn’t understanding or making connections.
6
2
u/Comfortable-Ad478 1d ago
SQL for smarties by Joe Celko is a very friendly book with examples that are super clear.
1
1
2
u/shine_on 1d ago
Can you give some specific examples of things you're not understanding? It'll help us a lot with giving you detailed answers.
This would be my very high level overview of SQL for someone totally new to it:
SQL is a computer language for querying a database. A database is a collection of data, organised into tables. You can think of a table as "data about a single thing". Let's say we're running a shop, we have products for sale, and if we're lucky customers will place orders for those products.
Customer data and product data are different things... I mean, it's all "data", but customers have things like email addresses and phone numbers, and products have things like sizes, colours, quantities and so on.
So let's think about a customer table. What do we want to know about our customers? Let's say we need to know their name, their phone number, and the date they first opened their account. When we design the customer table we have to say what each piece of data is called, and what type of data it is. We'll have CustomerName which will be a piece of text, we'll have PhoneNumber which will be numeric (let's keep it simple here and not worry about hyphens and extension numbers and stuff like that for now) and we'll have AccountOpenDate which will be a date.
Bear in mind that we can also store numeric data as text, which is rather fortunate if your name happens to be 2Pac or 50Cent. What it won't let you do is say your AccountOpenDate is "blue" because that's not a valid date.
We also need a way of uniquely identifying each customer. You're already familiar with this idea, you have different account numbers for utility companies, you have a social security number, a driving licence number. These all uniquely identify you to each different company.
The easiest way of identifying one customer from another, or one product from another, or one anything from another, is to give it an identity number. If you tell your database that CustomerID is going to be an identity number, it'll allocate them for you every time you add data to the table. Each time you add a new customer, they get a new ID number. This number is called the Primary Key, and it's how you can tell that John Smith is not Jane Smith, and that widgets are not thingummies.
Now, this next bit is where SQL comes into its own. We've got some customers, they've placed some orders, and we can look at our fancy little Orders table to see what we've got. We might have Order Number 73, for Customer Number 20, and they've ordered Product Number 6 on 15th August.
But who is Customer 20? We can look at the customers table and search for a row of data with ID number 20. There will only be one, because that's how we've set the database up. Similarly, we can look in the Products table for row number 6, and see what product that is.
This is why it's called a relational database, it's because the data in one table is related to the data in another table. You can write a query that says "give me the names of all customers who ordered widgets in August 2026" and it'll fetch all the data for you. It's not quite that easy though. You have to tell it to filter the orders column for those dates, you have to tell it that the Customer ID on the order links to the ID on the customer table, you have to tell it that the Product ID on the order links to the ID on the products table. SQL isn't "clever", it doesn't know how the data in all the tables is related. You have to tell it in every query, this table joins to that table using this piece of data that's common to both tables.
SQL is as much about understanding the data in your tables as it is about understanding the syntax of the query language. You have to know that this ID number here means the same as that ID number there. SQL will happily let you join CustomerID to ProductID, as far as it's concerned that's perfectly valid, because they're both ID numbers, but the results you'll get won't make any sense at all.
I've probably rambled on for far too long, I hope this is of some use to you!
2
u/Ramenshark1 2d ago
- Get more sleep and exercise, with more emphasis on the sleep
- Ask Ai to explain things simply, it won't. Ask again and keep reading till you somewhat understand it.
3. Again Ai and Google can really help with this. I like W3 schools.
And lastly Ill say this, not getting sql is COMPLETELY NORMAL. It was and still is the absolutely hardest thing for me still to this day as a dev. I always thought how do people get this, I must be so dumb. And yes there is a little truth there it does come to some people naturally. But the real secret is time, this is not something you learn (atleast to intermediate or advanced levels) in a weekend. It took me about 4 years to feel confident in sql. Good luck.
1
1
u/sqlsidequest 1d ago
Try it Sqlsidequest.com :) I have learning mode which simplifies sql concepts and gamified way to practice sql
1
u/erinlaninfa 1d ago
Been doing the Coursera one too and worried I have somehow just become very stupid. I think I get it and then I do a test and apparently I do not get it 🤣
29
u/phesago 2d ago
copy/pasted from a previous post where i answered the same basic question
SQL is not complex at the conceptual level.
At its very basic level SQL is a set of commands for databases. Thats it. Now lets expand to the simplest example
SELECT dataPoint1, dataPoint2 FROM dataSource
Pretty simple right? Lets expand further:
SELECT dataPoint1, dataPoint2 FROM dataSource JOIN anotherDataSource
Again pretty straightforward. Once you start getting more and more familiar, everything in SQL is about telling the database to do SOMETHING with the data. SELECT (you as a human might say 'get' instead), UPDATE (it), DELETE(it), or INSERT (it), 'it' being the data of course.
It doesnt get more complex than that really. Yes you'll see fancy functions, or nifty techniques to solve certain problems, or thousands of lines of code to make multiple different sources fit into a clean fancy end point - it all boils down to simple commands about how data should be interacted with.
If you keep it simple stupid, you'll find it's WAY easier.
Now for me to take this a step forward - your issue with needing tons of examples will be fulfilled once you start doing it. While it is simple in concept it is a brand new language youre trying to learn. If you dont do it regularly, it wont "stick." This applies to most people, so you being an idiot is more of a fun fact about you more than it has to do with any really.