Storing preferences in the database might be done like so.

create table prefs ( user_login text, color1 text, color2 text, fontsi
+ze text, ... , primary key (user_login) );
[download]

Later in Perl

use constant DS => 'my dsn here';

# later ...
my $dbh=DBI->connect(DS);
my($color1, $color2, $fontsize);
eval {
  my $sth=$dbh->prepare("SELECT color1, color2, fontsize, ... FROM pre
+fs WHERE user_login=?");
  $sth->execute($login);
  $sth->bind_columns( \( $color1, $color2, $fontsize ) );
  $sth->fetch;
  $sth->finish; # using primary key to only fetch 1 row
};

if($@)
{
  print STDERR "Informative error message goes here with $@ for good m
+easure\n";
}
[download]

This will bind color1 to $color1 etc. They will be undef if they aren't set in the database. Another option is to have a prefs hash so that you dont have a zillion named variables all floating around for a long time all doing the same thing. But if you ant to add a new preference type you need to alter the prefs table and change the code everywhere prefs are accessed.

#change lines from above
my($color1 ...); #becomes
my $prefs;
#bind_columns becomes
  $sth->bind_columns( \my( $c1, $c2, $fs ) );
  $prefs={ color1 => $c1, color2 => $c2, fontsize => $fs };
#later to get a pref
print "My favorite color is $prefs->{color1}\n";
[download]

The bind columns could be done other ways like binding directly into $prefs. This way makes the bind_columns short and makes the assignment to $prefs seperate so if it gets long it can be split over many lines for clarity. If you add a new preference this makes a new bind variable you have to add and also change the prefs assignment also which is a drawback. Another drawback is that a new preference type requires altering the prefs table in the database.

My preferred way to set up the table would be.

create table prefs ( user_login text, prefname text, prefvalue text, p
+rimary key ( user_login, prefname) );
[download]

Then prefs can be added as desired to the database and the perl code pick them up next time through.

my %prefs;
...
eval {
  my $sth=$dbh->prepare("SELECT prefname, prefvalue FROM prefs WHERE u
+ser_login=?";
  $sth->execute($login);
  $sth->bind_columns( \my( $n, $v ) );
  while($sth->fetch)
  {
    $prefs{$n}=$v;
  }
};

if($@)
{
  #as before
}
#later to use
print "My favorite color is $prefs{color1}\n";
# or even
foreach my $p ( keys %prefs )
{
  print "I like my $p to be $prefs{$p}\n":
}
[download]

Now adding a pref to the database will make it available in %prefs to your CGI programs. Any unset prefs in the database are not loaded into the hash at all and defaults could be used etc. This version only loads prefs which are defined for the current user into your address space and a new preference only needs to be referenced in the perl code and users which want that preference get it in the database and it magically is available in all scripts which access the prefs table to use as they wish. This method is very extensible and the primary key assures that each user has exactly 0 or 1 preference of each type.