Bootcamps upwards of $15,000???? How do people learn this shit without a disposable income or already being an autodidact?
Start here: https://sqlbolt.com/
It's an interactive tutorial. I find it easier to see the data laid out and how the queries interact with the data in the same place.
This can be hard if you have zero programming experience, but I find the best way to learn is to make something. You'll probably need to find a few beginner tutorials online, but making something tends to lead you in the direction of understanding it (because you have very specific things to search on google/stack overflow).
For learning SQL, I'd make something like a pokedex. You don't even have to make it a full-fledged application, just make a simple database that includes the kind of things you'd expect in a pokedex. Figure out how to insert into that database. Then figure out how to query that database (list all flying pokemon, list all grass pokemon from X region and fire pokemon from Y region, list all pokemon that appear in both X and Y regions). If you're feeling confident after this, you can start building a UI that displays this sort of information and has the filters built in.
That's the kinda stuff I do to learn a new technology.
autodidact is how 95% of people (have to) learn any computer programmy things. Our society is not built around accessible education or mutual teaching, which sucks.
SQL is a weird, mostly declarative language. A useful and good one, but it's a little harder to intuitively grasp than an imperative language. In an imperative language, you tell the computer what to do, step-by-step (create a variable with value 3, multiply it by 2, keep multiplying it by itself until it's greater than 1000). In a declarative language you say what relationships and results you want to see and the computer figures out how to get there for you. The latter hides more things from you, so what you're really learning is how to tweak the declarations for this one particular language and it's idiosyncrasies.
I would usually recommend learning an imperative language first, if you have the time and interest, because it's more intuitive and you'll pick up some concepts that carry over like data types, inputs and results. Common imperative languages to start with are Python, JavaScript, or Java.
If you'd prefer to just go straight to SQL, which is 100% legitimate, I'd definitely recommend some kind of quasi-interactive course-like material that teaches you pieces at a time, then has you apply them to realistic examples. Like others mentioned, it's also important to have a project where you want to use these skills. This is important for both learning and motivation. Your project will concretize the language and lead to a lot of Googling, which is 80% of how programmers figure out what to do when they hit a snag. A project will also tie into your motivations and keep you going: you're probably either trying to make something that you already use better or you want to accomplish something at your job/hobby that's otherwise impossible or you want to get a different kind of job than the one you have now, in which case your project is a resume-builder.
Good comment. IMO, SQL is basically useless on its own. It is a highly marketable and useful skill, but it is hard to learn in a vacuum. It is always being used as a tool in the context of accomplishing some broader goal, and those goals will strongly influence they way SQL is employed. Relational databases are a very important component of applications which need to store vast amounts of categorized data, but you will have no fun sitting in front of a Postgres/MySQL command prompt manually typing in fake entries for a fake schema for a fake inventory / billing application.
To make the most out of relational databases, you need to fiddle around with an application which USES data. This means learning some other programming language like Python, Ruby, Java, C#, Rust, etc. No need to master it, just learn enough get a gist of what it's doing. Write a script in one of these languages to fill up a database with some interesting information, or play around with an already-existing application which makes use of a database.
For instance, there are a bunch of open source media players that read tags from your media library and store them in a sqlite database for faster start-up. Try cracking that thing open and playing around with it (either from the software side or the database side). See how changes to the database are reflected in the software. See how changes in the software are reflected in the database. See how a somewhat advanced (but not enterprise scale) database is organized.
You can also try playing with a vast array of software designed for the web. Content Management Systems like WordPress and Drupal, message boards like SMF, social media software like Lemmy or Mastodon, Wiki software like MediaWiki. These all use relational databases via SQL queries under the hood, and the schemas / queries they employ are heavily optimized.
Iunno if this helps, but I always learned by cracking things open and having fun with it.
I'm not necessarily sure I'd agree that imperative would be easier to learn, unless you're digging deep into query plans and extreme optimization in SQL.
SQL has a relatively readable English-like syntax which is likely more familiar to beginners, and doesn't have to deal with Object Oriented Programming. Plus, I find declarative a lot more intuitive, especially for beginners, since you focus on what you want the computer to achieve, without as much care about how the computer does so.
Well my impression here is based on meeting a ton of people who have trouble learning SQL directly - or learn a little SQL and then give up because they "don't get it", vs. lots of folks who know one imperative language and then picked up SQL very easily.
Basically... there are a lot of people who are almost there in terms of being able to be good at SQL or generalize into making more through data analysis that requires dipping into imperative programming. It's like they hit a wall at mediocre SQL skills. I think this draws from not having a solid basis on which to build out their skills, instead just getting enough of what is basically a DSL for relational querying to be dangerous but not knowing where else to go from there. These folks find that situation discouraging and frustrating and I always put them down the Python or JavaScript path and it tends to work.
I didn't know sql before I got a job working with sql.
The issue with this is you wouldn't know if chatGPT is wrong and teaches you incorrect material
For the basics I've found it to be pretty good. So far i've tried it with projects in php, sql, unity and c#, some arduino stuff. The biggest issue I've found it having is that if you're using it to create a big project it will change the names of variables mid project. So like $perPage becomes $per_page after having it write like 5 queries. Also, its best practices for security is all over the place. :data-laughing:
he asked how to learn it, not for a quick cheatsheet
that also links to codeacademy.
I would argue that once you have the syntax down you have basically learned SQL and all the rest is database management which isn't so much an SQL thing as it is a database thing and there is free info online on that
SQL is pretty easy to learn the syntax is pretty basic.
It's basically select, update, drop, create, from, where, and, or
they aren't used very differently from how they are in english
you also have to learn the datatypes but it's pretty simple and $15,000 is more than I think you should spend
look up database normalisation online as well to learn how to design the database itself
Google "[thing] tutorial" and then when you're done with one you should have the tech set up to fuck around
This tutorial's pretty great, especially if you're trying to use it to do web stuff.
It's completely free and if you want at the end of it they'll certify you for $100.
I sometimes informally teach new hires on my team some SQL basics. Honestly the basic concepts are pretty intuitive when you sit down with them, since it's easy to make analogies to other normal life concepts. Indexes are like a table of contents in a book. Joining tables is a cartesian product which you tame by adding filter conditions. That naturally flows into why joining on indexes is more efficient, which leads to understanding table design patterns, and so on.
Then it gets hard when you run into the real life situations, and the endless edge cases and performance tuning that needs to be done in practice. And that takes a long time to get good at.
You don't. You learn C# and use .Net with Entity framework and just pray everything will work out ok.
Here's my thoughts after years of trying to self-teach myself SQL and getting to the point where I can comfortably write queries:
-
You'll need to find a sample database to play around with. Most of the basic features of the language is easy enough to grasp. The hard part is knowing when it would actually be useful. For example, self join isn't a hard concept to grasp at all, but the far harder question that you'll have to figure out on your own is when you'll actually use it.
-
Read up the Wikipedia article on normalization. For this, you don't even need to set up a SQL server to practice. You could just play around with spreadsheets and try to see if you understand the concept.
-
90% of learning how to code is googling "how do I do X?" and adjusting the answer on Stack Overflow to fit into what you're trying to do. Don't be discouraged that you constantly have to go back to the same page over and over again. Being able to completely type shit out of memory comes after years of experience. Don't be ashamed that you didn't memorize the syntax and have to resort to copying and pasting. In fact, you should have a SQL bookmark folder that filled with "how do I do X?" And many of those answers will have people that will explain why they did what they did, which is what you're trying to learn (see point 1).
-
This is something that's hard to explain, but a database doesn't just exist on a purely technical level but also represents human processes as well, so your queries will have to be with written with the understanding of what those human processes are trying to do using the database as a imperfect representation of those human processes. There's a difference between a query that sums the total of the fruit field where the branch office field is X and the fruit field is apple, a purely technical exercise, and a query that counts the number of apples sold in X branch office, a question that relies on understanding of human processes (do people in that branch often make mistakes when trying to key in the right item code for apple, do they often miscount the number of apples sold, does that branch office often have deals where apples are given out for free leading to confusion over whether the free apples being given out should be keyed into the database or not, do people count applesause as an apple or a jam).
-
