There are two key things that I think a student has to have to avoid floundering... a project, and a deadline.

It's really tough to sit down and just 'learn a product' I have countless examples of that in my own work. Without a specific project to give one's self some direction, the product is just too big.

And without a deadline, other projects seem to get in the way.

Many years ago (before Breck's awesome book which is already mentioned) I read a book called Joe Celko's SQL for Smarties... the edition I bought came with a CD containing a single user copy of SQL Anywhere. I don't know if the book is still available, but it's worth looking into.

There are really two things to learn for an IT guy with little db experience. One is the syntax of getting data in and out of the database and the associated apps (ISQL and Sybase Central) and admin stuff like backup and recovery.

The other is database design. I think the latter is far more difficult to learn -- or so it would seem based on the databases I've inherited. Proper database design comes easy to some, and for many others it seems to come easy, but they get it wrong, and they often don't discover that for months or years after the mistake was made -- when some new application requirement comes along that reveals the mistake and the requirement can't be made without a wholesale database design change.

Application programmers tend to design databases to make the current appliction project du jour easy to program, rather than long-term database design purity. Typical mistakes include breaking the basic normalization rules. It's something to watch for in code reviews.

In addition to Breck's suggestions (with which I fully agree):

It might seem superfluous to note that: Practise your SQL:

• Follow the tutorials by copying the code and make some changes/enhancements, e.g. by variations.
• Try to set up a simple database schema with a basic set of datatypes, connect tables by foreign keys, try usual query constructions with joins, group by and the like.
• Over the course of time, try to find out what SQL features are best used in certain situations, i.e. when to use a group by, when to use a join vs. a subselect and the like.

That may sound like a hard way (and it is) but IMHO that's the (best?/real?) way to learn successfully.

The last point I mentioned is particularly important, methinks, because knowing one's set of tools is fine but knowing when to use each tool is the way to mastery... Whereas one would seldom try to use a screwdriver when a hammer is appropriate, I guess it's quite easy (and common) to use one SQL feature when another one would fit much better. In lots of cases the suboptimal feature will work but usually lead to worse performance.

That all being said, don't get me wrong - I'm still on that same journey, too, and hope this site will help me to improve my skills (well, it already does so).

And I feel there's much opportunity to add questions and answers to these topics "What SQL do I use to answer that kind of question?" here. A bunch of them comes to my mind immediately:)