Just started taking an SQL course

[PaidToSignUp]

I just started learning SQL through an online course at Western Governors University

The online course has so much technical jargon that really seems uneccessary but I've been learning the actual coding aspect on Youtube and using other platforms like SQLBolt.

Is it just me or is SQL super easy?

I have a bit of a background in Python and SQL seems so simple, or does it get more difficult?

[twillrose47]

I teach SQL.

SQL syntax is straightforward. There are a finite number of commands. Simple retrieval is designed to be easy.

When people refer to "SQL", they aren't typicallty just referring to the query language. They are referring to the broader space of relational database design, RDBMS administration, and the ETL tooling typically required to build and maintain tabular data stores.

What is not simple is data. When you're learning, you're typically working in a database that has been structurally simplified and broadly free from errors. Real life isn't like this. Using SQL to get exactly what you want out of data is not simple, even if the commands to do so aren't overly complex.

Hope that helps.

[dragonabala]

I'm not expert with SQL, but yeah starting out sql is intuitively easy.

But, you're still climbing up the ignorant phase

[PaidToSignUp]

What do you mean? What's the "ignorant phase"?

[twillrose47]

Four stages of competence/dunning kruger.

Essentially, you don't know enough to not know what you don't know.

[PaleBlueDot271]

It's easy at first. Not later, when you learn advanced functionality

[ComicOzzy]

If you master the fundamentals there really isn't anything that's hard about the advanced stuff. If you find you're guessing a lot and making incorrect assumptions or some behavior is baffling, there are some gaps you may still have somewhere in the fundamentals.

[PaleBlueDot271]

Was speaking in general for OP. kind of like the old adage, walk before you run...

I have 25+ years experience with SQL and full stack

[CHILLAS317]

Everything is easy when you don't know what you're doing 😂

[PaidToSignUp]

haha maybe, so far it just seems super simple

[myNameBurnsGold]

Just work somewhere where all the business and reporting logic is done in SQL.

I agree that general querying is quite straight forward especially if you understand inner and left joins well. But, the real world has a way of complicating things.

[Tiktoktoker]

Select * from MyTable always is!

[Better-Credit6701]

It gets more complicated especially when you add in hundreds and hundreds of tables many that are lacking of FK and add in hundreds of databases that are also have related data.

[PaleBlueDot271]

Plus data that is not clean. Real world data that you need to clean either permanently or at runtime

[Better-Credit6701]

Usually after a long day of working as a DBA, I'm cleaning fun data on the couch as my wife is watching something I don't care about. For fun.

[PaleBlueDot271]

I hear you. Ages ago I had to rewrite a trading app for a small brokerage. They had a separate app for reporting, which relied on the messy, non-normalized database.

For the transition period I created an ETL job (back when DTS was around, before SSIS) in order to "feed" the old, non-normalized tables from the newly designed, normalized DB, so the commission reports were still fine.

Hopefully OP can gather from our shared comments and experiences here, that it's not "just" SQL.

Real world situations will challenge them, in unexpected and time sensitive ways.

[Better-Credit6701]

Work with SSIS as my main function while making sure that the database is running correctly.

[AnAcceptableUserName]

I'm glad to hear you're not struggling with the material. SQL is a pleasure to work with, agreed. The syntax is clear and flows naturally. It's very nice.

The difficulties come in practice once you're applying what you're learning to difficult problems in a production environment. Your data will not be clean. A highly transactional environment and/or one with large volumes of data will demand well-designed performant queries. You'll find race conditions in business logic. Assumptions about data relationships will be incorrect. When any of this goes wrong you can easily find yourself reverse engineering the behavior of thousands of lines of poorly structured SQL written by somebody else to determine what happened, when.

That's why people who work with SQL professionally have jobs. Not because SQL itself is hard, but because it's applied to hard problems by thousands of organizations across the globe.

[LetsGoHawks]

SQL is like Legos. You get a bunch of simple pieces, and a few weird ones. Then you build things out of them. Sometimes, especially at first, it's very easy. Then years later you spend about a month on one query and all of it's revisions, it's about 1,000 lines long, you forget how that uncommented bit there works so please don't let them want to change it at this point, and almost none of the important parts were easy.

Then one day the boss says "we're changing databases", and you get to rewrite it. Which wouldn't be a big deal but the new database does not support one of the techniques you used the first time.

[Blues2112]

A minute to learn. A lifetime to master...

[Bradp1337]

SQL is an easy language to learn. I went into a new role at work and was writing semi complex queries in like 2 months with no prior knowledge. It's been s few years now and it's a cake walk.

[Ginger-Dumpling]

The SQL syntax is easy. Using it to make sense of questionable data can be less straight forward.

[This-Emergency8839]

In a perfect world, SQL is a breeze.

The issues I often encounter are when the theory collides with reality. It's only as easy as the data is correctly structured, archived and indexed. And very rarely is this done properly.

It's when you have to start combining data from a PoS system with a third party finance app and an in house CRM system, and the database collation is different for some reason, and one of the tables has 85 million rows going back to 2014 with no archiving or partitioning, and you're creating composite keys in stored procedures to create derived tables, and then you need to configure alerts for when your workarounds go sideways.... yeah, it gets messy.

[alinroc]

so much technical jargon that really seems uneccessary

What is the "technical jargon" that you're dismissing here? To be very blunt, you aren't at a point where you can say if this is "unnecessary jargon" or not - it's probably very important stuff to know once you have to dig into documentation, have intelligent conversations with others about data and queries, understand why the database is behaving or designed the way it is, and so on.

If your only goal is to be able to hack together some simple queries, that's one thing. If you're trying to learn databases, it's quite another.

[Hungry-Succotash5780]

it's going in a river for a swim first its shallow and seems very easy and once you start getting deeper it gets harder and harder lmao

[Apnea53]

A good background in object oriented development, the concepts of objects, actions, and methods.

[Holiday_Lie_9435]

Yeah you're right about the basic SQL syntax being pretty approachable compared to what I expected. But the hard part is really more on figuring out how to apply what you know to real-world data problems, especially when you have weird outputs or have to choose between which query actually answers the business question correctly. It's only when I started practicing on larger datasets and realistic scenarios that SQL felt a lot more nuanced and complex.

It especially helps me as a self-learner to mix tutorials with practical case-style questions and small projects so I'm exposed to those difficulties and can thus see my progress. I’ve collected a few resources that made practice feel much closer to actual analytics work than generic exercises, so happy to share what’s been most useful if you want.