Slashdot Mirror


Beginning SQL?

$ynergy writes "I have been seeing more and more job listings for SQL programmers so, naturally, my interest as been sparked. I have picked up a few materials but, soon realized that it would be easier to apply if I had experience using database software. Would everyone agree? So I am looking for resources, online or in print, that would give a beginner a real in depth look at using database SW." There are at least two issues here: a) learning standard SQL (pick a standard, any standard :) and b) learning all the idiosyncracies of a particular database system. Probably learning basic SQL is the way to start.

2 of 50 comments (clear)

  1. Learning Database Systems by jefflinwood · · Score: 4, Insightful
    I would recommend that you learn either Microsoft's SQL Server, or Oracle 9i. Both are freely downloadable (for a trial, or for non-commercial purposes) from their respective web sites. A great resource for learning more is InformIT. Their database section requires you to create an account though.

    Some slashdotter's may tell you to learn MySQL or PostgreSQL because they are open source. This is true, and it's good because they come with almost any Linux distribution. Unfortunately, business aren't looking for those skills, so it won't help you.

    Here are some Monster stats (for open US jobs):

    • Oracle: More than 5000 (could include Oracle Apps)
    • SQL Server: 2686
    • MySQL: 101
    • PostgresSQL: 16 (under postgres, postgressql, postgresql)
    • IBM db2: 1100
    • Informix: 286
    • Sybase: 738
    • Microsoft Access: More than 5000.
  2. Design by highcaffeine · · Score: 5, Insightful

    Do *not* learn the actual query language first. Learn database theory and design before anything else. Don't even consider doing anything with a database until you know the six forms of normalization (at a bare minimum you need to know the first three; the second three are "gravy" for many applications and not even appropriate all the time). This includes knowing the requirements to reach each level of normalization within a database.

    I have seen so many database layouts for various applications that have practically brought me to tears through their sheer stupidity. These were layouts designed purportedly by people who "knew SQL." There is a tremendous difference between "knowing SQL" and "knowing proper database design and implementation." Unfortunately, many people who claim to be database programmers do not realize there is a difference and assume that since they know the syntax of SQL, they know how to design a database.

    I would recommend that you begin with "Database Systems" by Connolly and Begg. Read it cover to cover, then read it again. When you're done reading it the second time, skip through to the end of each section and do all the exercises without rereading any of the text. Once you can answer a majority of the questions correctly, then begin to consider designing database layouts. Before you look the book up on fatbrain or amazon, be warned that it is not light reading. It's 1,200+ pages, but is well worth it.

    The ISBN is: 0201708574.

    When you actually understand how databases work and how to effectively use them, you will thank yourself tremendously for taking the time up front. If you dive right in to learning the syntax of the query language without understanding the basics of design and implementation, you will make one stupid mistake after another with no end in sight. Then, someone more knowledgeable than yourself will come along and will have to start everything over from scratch to fix your screwups.

    Doing it right the first time is especially important when designing databases for large systems. If you screw something up and don't learn from your mistake until you have millions of records in tables that are being quickly updated 24/7, fixing that mistake is going to be a nightmare and could very well cost your company a tremendous amount of money through downtime and resources spent on the fix and conversion.

    Trying to keep this post from getting too long: the key is that there is absolutely no substitute for a solid understanding of the theory behind database design. You simply cannot be anything more than a witless hack at databases without this understanding. You will churn out terrible database layouts almost every time (unless you have an unbelievably lucky streak) and your projects will suffer because of this.

    Sorry if this sounds harsh, but it really, truly is worth spending the time to learn the theory and design before trying to apply your efforts to a real world project. Of course, if you're impatient you can play around with a server at the same time you learn the theory. But do not make the mistake of neglecting the theory in favor of quickly learning the syntax.