Some jobs of the type I want to apply for (GIS) have listed experience with SQL and MySQL as needed skills. Would it be hard for a non-programming person to learn? I had one class session (one 2 hour class) in Python a few years ago, and I did web pages in HTML long ago, otherwise I know nothing about programming or computer languages.
If I wanted to learn, what would be the best, easiest, cheapest, and fastest way? 
It’s VERY easy. I taught myself SQL in about a day, and I’m no hacker. If you can find a halfway decent textbook and an Access or MySQL practice database to experiment in, you’re set.
On edit: Databases themselves, on the other hand, might be a bit harder to learn if you have no programming experience. Do you have MS Access on your computer? Beg, borrow, or steal a textbook on basic DB’s and go from there, paying particular attention to what a database actually is, as well as what a record, table, form, query, and report is. Basic DB theory and practice isn’t hard either, but you need to put in some practice on it. Do this first, and then teach yourself SQL once you know your way around a database.
I would agree 100% PROVIDED you have a logical mind. SQL is very logical, but not everyone has that type of mind. I used to manage databases and some of them got to be a mess 'cause of lack of logic.
Another thing to consider is rational databases. A lot of so called rational databases are not in reality rational.
The problem you will run up against, as I have when I apply for jobs is the companies have databases which are a mess and expect you to clean them up. And they aren’t going to like the answer.
But if you mind can follow logic and steps A->B->C->D , then learning SQL will be easy
SQL takes a minute to learn, but a lifetime to master.
I just recently had the OP’s same dilemma, but it was solved for me when the job I took (which didn’t list SQL as a req) eventually ended up needing SQL anyway.
I found it very easy to learn and I echo the statements above, but with my own caveat that I am indeed a programmer and past DBA.
The other thing I’d mention is that it can be somewhat difficult to set up for the first time, if that’s what’s expected, and it can be quite a bear to program an interface to, especially because all of the different types of SQL (there is no standard), though this depends largely on what language you’re using.
If you’re just using it, and are at all familiar with programming spreadsheets, SQL will be a breeze.
Oh, and my method of learning was to type “SQL tutorial” into Google and reading what came up.
Anyone can make simple queries fairly quickly. But that will only take you a short distance, learning the intricacies of doing complex queries and transformations in SQL is not something people pick up quickly, or in many cases, ever.
Thank you.
Saying SQL is VERY easy is like saying painting is easy because you were good with your fingers when you were five years old.
People who think SQL is easy are the ones who end up with the over-complicated nonsense query running for hours, setting the DB on fire and taking everything else down with it.
+1.
Learning basic DDL stuff and how to do “SELECT *” is easy.
Learning how to deal with subqueries, unions, groupings, complex joins, (and understanding the difference between inner and outer joins), the proper use of NULLs (do not fear NULL. NULL is your friend) and other topics is a lot of work. But like any programming language, you can progress from “Hello World” to the harder stuff with regular effort.
Agreed. I’ve been in GIS since before it was GIS. AM/FM, Automated Mapping and Facilities Management was what it was called in 1987.
I use SQL fairly regularly, but don’t get to deep. It’s very easy to make a mess if you are not very careful.
I suspect, if you are in GIS, you are talking about ESRI stuff? SDE (spatial database engine)? You really, really don’t want to touch that database with tools other than those that ESRI provides (other than backups and such).
I use SQL mostly to analyze and fix problems on other databases. It’s very, very handy.
A bit of SQL is a great tool to have in your shed. As others have said, practice a bit on an Access DB. You can get all the commands you need online for basic statements.
If you are just breaking into GIS, on the ESRI platform (an assumption) you will have very, very little need for SQL (if any, I’m the only one in our department of 4 that uses it).
I would be happy to try to answer any questions you might have about a GIS shop.
Good luck.
Well, when I said it was very easy, I didn’t mean that it was as easy as something you did when you were five. But I went straight from that day of being introduced to SQL to using it on the job, and no DB’s burned on my watch, and I’m no genius with computers. I also used complex joins, null values, and subqueries without much trouble. I would say it’s like anything else. You have to learn the basics and the intermediates before you go all out, but that said, I never saw anything in SQL that was too hard. Just about anything can take a day to learn and a lifetime to master.
Then again, I did have DB experience before SQL thanks to Access, and I knew the database basics. But really, you could say that about any skill in life. Keep it simple, keep it sweet, and don’t do anything in the real world before you practice.
Just my $0.02
Didn’t mean to come off so accusatory, I meant a more general “you”. But…
You’re talking about features of the language, I’m talking about the consequences of using that language. Sure your query compiles (general ‘you’, again), but what does running it do to the server?
I’m not trying to be discouraging, but I am a bit tired of cleaning up the messes of people who jumped in too fast thinking things were “very easy” when in reality they were just very short-sighted. SQL is very easy to get started with and just as easy to get in over your head.
What you’ll need is not just logic, but abstract symbolic logic.
If you’re good at logic games, puzzles and such, you’ll have some grasp of it.
If your logic takes the form of words and sentences, you’ll have to learn it like a foreign language.
I’m with Discipline, ultrafilter, and the others of their opinion.
It takes next to no time to learn to write a simple select query.
It takes a LOT of time to learn how to write elegant queries that return the data you want in the order you want it without bringing the server to a standstill. Heck, I’ve been doing SQL stuff on and off for the bulk of my career (20+ years) and I still occasionally need to go to my uber-SQL-guru friends every once in a while for help with getting a query just right.
As far as the OP goes, it depends what skills they want. Do they just want you to be able to open a DB and run a few pre-packaged queries? That’s not hard to learn. But if they’re looking for someone who really knows what they’re doing, you’re not going to learn that minimum of a year or two of real-world experience on the job.
Thanks everyone! Most job descriptions I’ve read just state they want someone experienced with SQL. These are all entry-level jobs, so I would think they don’t need a SQL master. The database experience I do have is with ESRI’s ArcMap and I’ve done a little bit of manipulation with it, running queries and such. I don’t have that software on my home computer (Mac user), but I did find some tutorials online and have worked through a few…I guess I have experience now.
As with the other practitioners above. Easy to get started, hard to be really good.
Another point not yet made …
There is also a gigantic conceptual leap from “I can write good queries to extract data from this (fairly-) well designed database full of data.” to “I can interact with the business users to determine their needs, then build a conceptual data model which accurately capures those needs, then build a database to store that model, and the set of procedures to insert, update, and query that data in a logically consistent fashion over time.” And to backup, restore, import, export,and update all this over time as the business or technology changes.
A lot of SQL-related work starts out with “We just need you to create a report on XYZ from this existing database”. Not too hard. But the water gets deep quickly.
And very often the business doesn’t understand that to get the meaningful report on facts A, B, and C which they so desparately want, they need to have some way of capturing the upstream facts Q, W, and E. Which they presently don’t have.
Only if you understand the business significance of what they’re asking for and have the business process, logical, (and sometimes statistical) chops to determine how that really maps into their data model can you really create a good result. And then use SQL as the low-level tool to generate that result.
As a micro example, here Why does SQL assume you don't want to indlude NULLs in queries? - Factual Questions - Straight Dope Message Board is a recent thread which touched on a situation with a very naive database design and a sorta-naive self-taught data base operator/SQL coder getting tripped up. And notice the 17 varying opinons from experts on the goods and bads of the underlying issue.
As with most things, a lot of harm comes from people running just outside their own sphere of knowledge. They’re tripping over their own unknown unknowns. And (of course) they don’t know it. Don’t be that person.
Just like Hungry Hungry Hippos!
Mrs G picked it up over a few days. Check your library also, for free instructional software.
SQL is simple - partly because, as a language, it has a fairly small vocabulary and partly because some of the complexity of operation is embodied in the structure of the databases you’d be querying.
But being simple doesn’t necessarily make it easy. It’s really easy to get started with, but some of the advanced stuff you might have to do in the real world isn’t easy or necessaily intuitive.
Being the administrator of a DB management system such as MySQL is another different set of skills altogether.
SQL is my next challenge after VBA and XML. A colleague who is helping me with SQL referred to learning SQL after VBA as learning Chinese after English. VBA has hundreds of commands which can be combined in many different ways, in which the order is crucial. Sort of like English, with a large vocabulary with a lot of potential permutations, but you look really dumb if you try saying something like “Typing I was.” SQL has fewer commands and less syntax rules, but like Chinese you have to infer a lot from simplicity of the commands, else you lead to big misunderstandings.
As an aside and an explication of what I said above, there’s an extremely similar issue in VBA with NULL records. Difference is with VBA that you can brute-force your way out of the situation, without causing too many problems. Or you can find a way to cheat VBA–in the Excel document I was coding, it was a simple thing to throw in a few lines that temporarily turned NULL records into " ", without taxing the system overmuch. That’s just not happening in SQL.