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).
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).