Databases in general and Perl go well together with modules like DBI and DBIx. The nice thing is that those paper over many of the differences between different (SQL accessible) databases by allowing pluggable back ends. There are a large range in the DBD name space.

As for an address book. What is it if not a database?

Take a look in the Tutorials section for Database Programming. Super Search for things such as DBI, DBIx, MySQL, SQLite, DBM::Deep and so on. It's a hot topic around here.

They suggested writing an address book and accessing it, and I realized that this could be a great way to learn about hashes.

You could do this with hashes, Data::Dumper, and do, or you could do it with DBI. If you want to learn to do database stuff, DBI is good way to go.

Actually it sounds like a reasonably good excuse for learning Class::DBI. For the backend, yeah, MySQL (with DBD::mysql) is fine for your requirements or you could even use DBD::SQLite. I assume you know how to install modules from the CPAN?

MySQL is a relational database, and you can implement address books (and other data storage schemes) with it and access its dbs with Perl. Once you know how to use MySQL there are Perl modules mentioned in the other replies you can use to talk to it.

IMO the Perl side is pretty straightforward--you connect to the DB, issue a MySQL command, read the reply into an array or something and use it just like any other data in Perl.

The learning curve is more on the MySQL side, and you should learn that before you try to run it with Perl.

A database of sorts does seem to be the way to go, but the concept of "database" doesn't automatically imply something as robust as MySQL (which belongs to a class of databases called RDBMS -- Relational DataBase Management Systems).

It looks like what you're interested in is a category of problem called "data serialization" -- storing data structures (usually to disk) for later retrieval. There are plenty of modules to do this, including Storable and DBM::Deep.

Considering that you're trying to learn more about data structures, though, I might suggest you look at one of the human-readable serialization formats, like YAML.

You can serialize data to database systems (even RDBMS) as well, but I'd tackle that separately from learning about managing data structures -- no sense piling your plate too high (do the simplest thing that could possibly work!). When you're ready, you'll want to grab a book or two on Relational theory so that you can design good uses for RDBMS. Then, you'll want to check out the DBI module.

You're probably too focused in on hashes initially. The best way to start is to do some research on data structures, then decide how to structure your address book in a more abstract manner. Once this is done it would be easier to see how you could use hashes to implement this project.

An address book actually is a good project for learning how to structure data, since you can start with a basic flat list and evolve it into an arbitrarily complex contact management system. This could give you the opportunity to play with a variety of data structures.

but with the hypothetical user constantly adding new fields within new fields within new fields, ...

Can you expand on how you see these things? (Newbies often have a refreshing new look on old problems, unhindered by tradition, so that's why I'm curious.)

It would be indefinite because the user would have the ability to create new fields of information, and new fields could beget new fields.

i.e. One person has multiple web addresses, the user could categorize them under "web addresses," a field they add in, under which could be sub-categories "work," "personal," etc.

C(qw/74 97 104 112/);sub C{while(@_){$c**=$C;print
(map{chr($C!=$c?shift:pop)}$_),$C+=@_%2!=1?1:0}}
[download]