Any and all advice is welcome.
Given someone that has an IT background but no specific database experience, what would you recommend they do to get started?
I'm looking specifically for books to read (if books are even a good idea), websites to check (this one for sure), and any other resources that would be helpful.
If you had it to do over, how would you learn it all over again?
Read the Help, especially the tutorials.
Read the blogs. Start with http://sqlanywhere.blogspot.com/ then follow the links to other blogs (see the blogroll "Focusing on SQL Anywhere...").
Ask questions here... ANY and ALL questions are welcome as long as they have something to do with SQL Anywhere.
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.
answered 26 Sep '10, 16:20
In addition to Breck's suggestions (with which I fully agree):
It might seem superfluous to note that: Practise your SQL:
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:)
answered 26 Sep '10, 13:48