I've never had much need for programming with databases. Since their use is so widespread it seems like a good thing for me to learn. SQL seems like the place to start, possibly SQLite and maybe the Python bindings. What would you recommend for someone new to this? Libraries, tools and project ideas are all welcome.
If you program using the .NET framework, then learning LINQ might be a good place to start. The LINQ "engine" will handle the back end communication with the database (or objects, or entities, or XML, etc.) for you. If you want to dig deeper, you can explore the SQL generated by the LINQ that you write.
If you already know a thing or two about web applications, then that would be a good place to start. Nearly every serious webapp uses an SQL database as its backend.
Try Wikipedia, http://www.w3schools.com/sql/default.asp and http://www.sql-tutorial.net/ Also check YouTube for SQL Videos.
The folks at Head First have come out with a book. Going by how good their other books are, I'd recommend this one. Haven't read it yet though. (LINK)
You are correct, SQLite is a great place to start because it is free, lightweight, and available on many platforms. This is only a start though. SQLite is very liberal on SQL syntax and lacks an intneral programming language like DBMS systems have. Still, if you want to start and learn with minimal overhead, SQLite is the way to go.
SQLite is nice and they have really nice documentation, however you should be aware that it is not a full featured SQL database like MySQL, Postgres or the commercial variants. SQLite's API relies on callbacks which is a fine model, but not all database APIs work that way. If you are familiar with Perl, then DBI is another nice way to explore SQL.
/Allan
Structure Query Language (SQL) is the language used to talk to database management systems (DBMS). While it's a good thing to learn, it's probably best to do it with a project in mind that you'd like to do. It's funny you say you've never had a need, because I'm the opposite, almost every program I've ever written has used a database of some sort. The vast majority (mostly web-based) revolve around using a database.
Learn about relations and database architecture. This means how to structure your tables, make foreign keys and relations.
For example, you might have a movies database. In it, you store information about the Movies, Studios that released the movies, and the Actors in the movies. Each of these becomes a table. Each Movie is released by one Studio. Since you don't want to store duplicate the studio information (address, etc) in each Movie entry, you store a relation to it, so each Movie item contains a reference to a Studio item. This is called a one-to-many relationship (one studio has many movies). Likewise, you don't want to store Actor information for each Movie. But one Actor can be in many Movies, so this is stored as a many-to-many relationship.
Learn SQL itself. SQLCourse is a good place to get started, but there are many other books and resources. SQL is a standard, but each RDBMS has its own vendor-specific ways of doing certain things and other limitations (for example, some systems don't support sub-queries, there are several different syntaxes for limiting the number of rows returned, etc). It's important to learn the syntax for the one you're using (eg, don't learn Oracle syntax and then try and use it in MySQL) but they are similar enough that the concepts are the same.
Tools depend on the DBMS you use. MySQL is a pretty popular database, lots of tools are available, and lots of books. SQLite and Postgresql are also quite popular, and also free/open-source.
You may want to consider starting with MySQL as it is widely documented and very easy to get started with. You can download the Community Edition and then add the GUI Tools and you'll both GUI and command line interfaces.
If you can, you really want to find someone who knows how to use it, and pick their brains. That's because there are a lot of important principles (eg 3rd normal form) which will are a lot easier to learn through discussion rather than from books.
If you want to teach yourself, you should learn the syntax for doing basic selects, joins, updates, deletes, and group by queries. You should also learn the "Swiss army knife" of selects, the CASE statement. Too many people don't. Many of the tutorials recommended in this thread will do that. Then you need to try to solve SQL problems. I'm sure that Joe Celko's SQL Puzzles and Answers is a good source of them, though it may be a little advanced.
This will let you actually write SQL. But you still need to learn how to organize a database. Which for most purposes means that you really need to learn what 3rd normal form looks like. You don't have to be able to give a formal definition of it, just recognize it when you see it, and know how to adjust something to be in that format.
Lots of references will explain it, but you won't know if you're reading them correctly. This is where it really, really helps to have access to someone who can look at a table layout and tell you, "That's right" vs "That's wrong, here's what needs to be changed." Failing all else, you could post a question here with a proposed layout. But a back and forth discussion with a live person would still be preferable IMO.
"A Gentle Introduction to SQL" - You can even practice "live queries" right on this tutorial website.
http://sqlzoo.net/
I always recommend The Practical SQL Handbook for a good starting point for beginners - especially those who have seen SQL but never understood how to build up a query them selves or how they work.
All Celko's books are great.
Hernandez's Mere Mortals book is good.
Ken Henderson's books are also excellent.
Reading up a bit on relational algebra is a good way to understand the underlying concepts of relational databases.
Read a book to start learning about SQL. I read Beginning SQL Queries from Apress not long ago, and found it clear and logically written for a beginner (I reviewed it for a colleague).
I learnt 90% of what I know about SQL from here. In 1997.
I think it still stands up.