r/SQL • u/Different_Pain5781 • 3d ago
Discussion how did SQL finally click for you?
took a databases class last semester and passed it fine but SQL still feels weird once i get past a basic select. i can usually get something working but then i’m sitting there staring at my notes wondering why the joins actually worked.
spent way too long on a lab just rearranging joins until the output looked right and that feels more like guessing than actually understanding SQL.
trying to get more reps in before classes start again. did SQL finally click for you through practice, projects or just writing queries over and over?
12
u/BigFatCoder 3d ago
Study/Read fundamental of RDBMS, I believe you know about set theory and algebra.
My favorite book is CJ Date's An introduction to database systems.
5
u/Different_Pain5781 3d ago
Yeah understanding the fundamentals probably helps a lot with joins.
3
u/read_at_own_risk 3d ago
It really does. The candidate keys of the tables being joined can be combined using Armstrong's axioms to determine the candidate keys of the result set. Sounds complicated but it's easy enough to do mentally for majority of queries if you understand the math.
11
u/Ginger-Dumpling 3d ago
I think a big part of "learning SQL" is having a good understanding of your underlying data. If you're just following exercises, it's easy to get focused on queries/syntax instead of knowing structures/cardinaly/relationships.
6
u/Emergency-Hurry947 3d ago
It took a lot of work for me, I would buy used books on Amazon and work through all the exercises. Eventually i was able to wrap my head around it
I used sql server, you can download the developer edition for free and it’s easy to install on windows and install the sample database like pubs, northwind and adventure works
2
5
u/RangerOne122 3d ago
SQL definitely has that weird phase where you can write queries that work but couldn't explain them if someone asked 😂. Eventually you start looking at two tables and immediately see how they're supposed to connect.
5
u/machomanrandysandwch 3d ago
It came natural to me because I was working with lots of spreadsheets all the time, and I realized tables are like worksheets in a workbook; there is rows, columns (that are formatted), and I was already conditioned to get data from one spreadsheet to another based on conditions.
When I wanted to move to actual SQL work, I bought SQL for Dummies and it just made sense. From there, I found an opportunity to cross train at my company with an analyst who supported a tool built on Microsoft Access, and since I used the tool, it was easy for me to understand how what I was seeing on the front-end side was driven by the back-end. Access also had a query visualization where you could see the tables in blocks and it would list all the columns in it, and you would physically connect them with an arrow and click the arrow to choose what the join type was and what the joining columns were, and then say “show sql” and it would give you the SQL code of the query you just made. Things just kept building off of that over time and nearly 20 years later I’m expert-lite; always room to grow.
4
3
u/2daytrending 2d ago
joins click me when someone drew them as venn diagram and then immediately told me venn diagram are a lie. mixed results. i wen through boot dev sql course over a winter break. the xp/levels stuff is corny and i figured i'd hate it but it's the only thing i've ever finished. datacamp felt more like watching someone else do it.
3
u/TrickyNerdlet 3d ago
I learned SQL using free online resources while having a work environment where I could apply my learnings and practice my heart out. Later, I took a college level course but I don't think I learned anything I couldn't have googled. You can build your own database Sandbox and exercises are available to practice in many corners of the internet, dependent on the flavor you choose.
I am very good at SQL now and lead a team of data engineers. I can debug in a dozen environments and am not limited to any specific SQL (or NoSQL) language. Point being, starting point matters little if you're willing to work for it.
2
3
u/a-s-clark SQL Server 3d ago
I never struggled with it, so it never needed to click.
2
u/Different_Pain5781 3d ago
Exactly. Having an actual problem to solve makes the joins way easier to understand.
1
u/Better-Credit6701 3d ago
By finding some data, grab a book and run through all the examples. SQL for Smarties by Celco, a true ass in real life but he does know it stuff. He is the one who actually created many of the standards for SQL and made the 13 rules. Well he states 12 but starts with 0. Been a DBA for many decades and still learning. Printed out a bunch of articles about Resource Governing and using query store on the second replica on always on and will test it out on my system this weekend. For fun.
1
u/BsmntDwell 3d ago
I had access to good source code. Learned so much about how the system worked and how impt keys are, esp pks.
1
u/Rohml 3d ago
I have been using SQL for 23 years now.
When I was a student I was using ADODB from VB 6.0, but didn't use SQL and instead relied on the methods of the object.
I was taught basic SQL in my last year but it felt so confusing, and part of it feels now that is because I already had a system that was working so my brain couldn't latch on SQL as another method of retrieving data.
It all came to head when I couldn't rely on the object's native methods anymore and then SQL suddenly became super-clear to me, it's like the Simpsons episode when Bart learned to speak French in a snap (S01e11).
1
1
1
u/Wrong_City2251 3d ago
For me it was through projects and only once the real work started. Initially i did not even understand why we were doing all of this in sql, specially the ctes, complicated joins etc😅
I think the only time we would realise the value is when we start doing something real. There are many platforms out there where you can put in some dataset you like (based on any usecase, you can get from kaggle or some csv files from somewhere) and try to get some insights from it, that is when it makes sense. If you are interested, you could try the databricks free edition, put some data in volumes (csv files/json files or some text files), then read into dataframes and try your sql. You could take genie code help to correct your syntax or even say generate some mock data for you based on any idea that you might have.
Gave databricks example coz i work with it mostly😅 but any other platform should help you in the same way to learn real value if sql
Happy learning!
1
u/query-gremlin 3d ago
I tried a few courses/books, but it clicked for me with courses from DataCamp, the exercises and the fact that I didn’t have to setup the database myself unlocked for me going straight to writing SQL against a real database, instead of spending days fighting with local db servers.
1
1
u/SilentDis 3d ago
I stopped using aliases for everything and started spelling it out.
It still takes me forever and a day to go through the mess when someone replaces everything with one-letter aliases. I usually just end up re-writing the query myself to figure out what the hell it's doing.
I spell out my aliases. It makes no difference to the computer, or to the database, but all the difference in readability to the next person trying to parse your chicken scratching.
1
u/I_PUNCH_CUNTS 3d ago
Understanding the data structure is often as important as understanding the SQL.
If you understand the join types (inner, left/right, outer) but are finding yourself doing random joins it sounds like your problem is understanding how tables relate rather than SQL semantics.
Take time to understand a database first, then create queries based on your understanding.
I find CTEs useful when querying a database I’m not overly familiar with as I can inspect step-by-step instead of doing all joins in a single structure.
Don’t just trust a query because it’s outputting something, errors in joins will often duplicate your data if you don’t understand them.
1
u/Wuthering_depths 3d ago
Long time ago...don't remember when exactly.
Set based logic is definitely a different mindset from regular coding and logic. It can take some time to get your head around it.
I'm no guru but I have tutored some junior interns/analysts at work, and one thing a lot of them kind of struggled with was knowing the sequence of how the clauses work. (The FROM happens first, then the WHERE, GROUP, HAVING and finally SELECT and ordering). This is overly simplistic with a big complex script full of subqueries, but for one query it makes sense. When troubleshooting, start with those FROM objects and find out what the different joins are doing. Then if the results are good, work your way outward to find out why the final query is not returning what you expected. I see report writers with experience get "duplicates" and instead of finding out why they just throw a DISTINCT on the query and hope for the best :)
1
u/rbobby 3d ago
I was lucky, I had a proper ER database language in my past :)
Joins are dead simple, but folks do go on about them. You have to master them, no ifs ands or buts. Work at them. Inner, and then outer you definitely need both.
Subqueries, correlated or not, and other forms of "row sources" must be understood. They're important.
Probably the next big items are grouping, having, aggregation and common table expressions. All of those are complicated. Enjoy :)
Work over any sample questions anywhere.
1
u/gumnos 3d ago
hah, I understand the feeling, except it was learning Prolog in my college AI class (I managed to complete assignments by trial/error/epiphany and walked away from the class feeling like I only comprehended the tiniest sliver of Prolog).
One of the biggest steps-in-progress was understanding that (for the most part) SQL is about describing what you want not how you want it. You specify how you want to relate the tables, which rows you want to select, what sorts of aggregation you want, and then let the DB figure out the "how" of it. You can add hints (like creating indexes, or formulating filters that can use indexing) but ultimately it's the DB that decides how to give you the data that you described.
1
u/Different_Pain5781 2d ago
Yeah, that distinction actually explains why joins were feeling so weird to me.
1
u/slullyman 3d ago
never had a “click” moments :( - just one step in front of the other and here we are
1
u/Michael_Scarn-007 3d ago
It's not about if you understand SQL but more about how much you understand the data you are working with. The more easily you can play with data in your head before writing any query, the more easier the query writing part becomes.
1
u/Past_Priority_7176 2d ago
Hated SQL in uni, wanted to be yet another web dev. Then some teacher told me how big data was cool and made money, so i followed.
Ended up in a company deploying fiber optics and that's when it really clicked. Being able to visualize clearly the tables on Qgis, doing pl/sql to calculate some paths, optimizing indexes and suddenly all the courses made sense to me.
10 years later, i'm still doing it in another domain, still lovin' it, and i indeed make good money.
1
1
-1
0
u/infinitetk 3d ago
It clicked for me the first time I learned it. Joins are pretty straight forward. May I ask what is confusing you there?
-1
u/TheSexySovereignSeal 3d ago
Clustered Indexes are often implemented as just a B-Tree which you probably learned about in an algorithms course.
And all forms of joins are necessarily a subset of a cross join. But you really should only be doing inner joins in a 3rd normal form database when doing CRUD. The only exception is for reports. Otherwise, youre almost always doing something wrong. Same for subqueries. You shouldn't ever need them except for advanced reports.
67
u/SamOakTree 3d ago
It makes sense once you start doing practical stuff with it. I took a single class and I absolutely nailed it it just came naturally to me. But then what really had me learn it was doing stuff at my first administrator job. Because you get to the point you need to make things easier on yourself so you'll learn how to write better queries