I’m not sure you have a good understand of what a database is…

A database is just a way of storing and structuring data that can be retrieved using a query language (typically SQL). A “database of recipes”, is useful only when you have an application that talks to that database. Without a database-driven application, it’s probably more efficient for you to store recipes in a Rolodex than in a database.

Fluther, for example, stores questions and answers in a database, but the thing that makes Fluther useful is the application code (written in Python using the Django web framework).

It sounds like the best solution for you is an application like Recipezaar, which allows you to save your recipes online.

If you insist on using a database, I would recommend MySQL or PostgreSQL. For what you are attempting to do, either one should be more than sufficient.

Check out http://dabbledb.com. It lets you quickly import data from a spreadsheet, and build a “relational database” out of it, almost without you knowing that that’s what you’re doing. It also lets you setup web forms that you can collect data from people. We used it recently to help us screen roommates on craigslist. Check out the screencast on the main page.

One of the important capabilities a database has over a spreadsheet (e.g, Excel), is that you can associate multiple records with one or more records.

For example, say you have a list of contacts, but you want to record donations they’ve made. For each donation, you want to store the donation date, and the amount.

One way to do this is to add columns to the spreadsheet like “donation date 1, donation amount 1”, and keep adding those columns to accommodate multiple donations. This works, but it quickly becomes unwieldy. And the more fields you want to associate with a donation, the worse it becomes.

Another option is to have just one “donation date” and “donation amount” column each, but then duplicate the a person’s record for each donation, storingdiffe rent donations on different rows. But then you have the same person in your spreadsheet multiple times. And what happens when you want to update or delete a person’s information? You’d have to update the same person once for each donation you made. See the problem?

If you have these kinds of relations to represent, using a database is a good idea. Unfortunately, until recently, there were few novice level database design products out there (afaik; Microsoft Access is an attempt at one), so it hasn’t been easy for people to make databases for relatively modest purposes. Dabble DB is the first one I know about that does this elegantly (For the record, I have no investment them; there may be others out there).

As stated, for personal use, you probably don’t need a database server like MySQL or PostgreSQL.

You may want to look into Oracle…(j/k).

Learning relational databases is not something you can do in an hour or two. If you want to play with something and have Windows, you may already have Access.

If not, the latest version of OpenOffice.org includes a database application called Base, that will probably suit your needs.

I use MySQL for 90% of my web projects and MS SQL for the other 10 percent.

”...and MS SQL for the other 10 percent”

Reason?

Try out OpenOffice.org and it’s ‘Base” application for a easy(ish) entry to db stuff. dabbledb above was a good suggestion too.
http://www.openoffice.org/product/base.html

The reason for using MS SQL on the other 10% is maintaining projects that I didn’t develop that were written in .NET.

you use databases everyday… this site is a database, so is your address book and calendar.

If you need to maintain a list of information/data with multiple “elements” (pieces of info), then use a database (2 good free ones are: http://blist.com/ or http://db.zoho.com/)

A simple database is your grocery list…if you organize it by food type! I.e., JUICES: apple, cranberry, orange; BREAD: pita, sandwich; & MEAT: chicken, pork, hot dogs.

Anything can be a database…