Friday, July 24, 2009

learning SQL

1. Get yourself a large database to play with. If you don't have database software, I suppose you'll need to either a) learn how to install it (almost everyone has a free version) or b) ask someone for access to one of their databases (someone where you work might have a development box you can hack away at).

2. Get yourself a good reference book. Everyone I know still looks stuff up. Alternately, you can look stuff up on the web but I like knowing what my database is capable of AND what the others are capable of, which makes this book invaluable.

3. Look over your sample database. Ask yourself questions about the data. Imagine what users will ask you. For instance, how can I find all the stores in Michigan? How can I find all the top-grossing film at all my stores? How can I categorize and label films based on high-sellers, medium-sellers, and low-sellers? Can I categorize and label the films without touching the database design? Who acted in the most movies? It can be (well, arguably) fun to insert some random bad data into your database to make answering these questions harder. What if you have a null to skip over? What if only half the items get filled in properly? How do you workaround this? How can I do these things using a single query rather than two or three?

4. Once you have answered some questions, learn how to deliver those as something people can use. How can I get the data into Excel? On the web? Into a google document? Into a pretty looking, printable thingy? All of those things are important.

Lots of database books start off with how to layout and normalize data (i.e. "database design"), but the times I've needed to do that are somewhat few and far between compared with when I've needed to use data effectively, so I submit that might be a better place to start.

No comments:

Post a Comment