If you really wish to learn about database usage, it would also help to learn about database normalization. One of the biggest mistakes that I've seen developers make is to try to build moderately complex databases without understanding this topic.

Here's a simple example: consider what happens if you are creating a database of book titles and one of your fields is for author. You, being a database-savvy kind of monk, know that you want a separate table for authors. If you hard-code the author's name into 30 book records and then you discover that you've misspeeled [sic] the name, you need to update 30 records. With the author in a separate table and the book record pointing to the author's record in the "author" table, you only have one place to update the author's name.

But wait! What about collaborations or anthologies? You could have several authors for one book and your "author_id" field in the "book" table doesn't work. You actually have what's called a "many-to-many" relationship and with most relational databases (multi-value databases are an exception) you need to create a new table that both the "author" and "book" table point to (you'll understand why when you read about normalizing).

As much as I hate to mention Microsoft, they have a nice overview of the basics.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.