Your Hash structure is fine. I would extend it a further bit and put all the 'names' in the array, thus you don't accidentally run into problems when there are 2 Mike.

$employee = { name => 'Mike Smith' , age => 31 , ...}; 
push @employees, $employee;
[download]

artist

I agree that some sort of serialisation would help, but not necessarily XML. Others have suggested DBM or SQL databases. Personally, I find Storable quick and easy for this type of thing. If you want to use SQL, you might want to consider SQLite which I've used recently for several lightweight database applications where I didn't want a fully featured relational database server.

I like XML and use it where appropriate, but sometimes developers seem to use XML because they think everyone else does it, or because it's fashionable at the moment. If it works for you as a serialisation method, fine, use it, but make sure you consider the alternatives.

I disagree with the idea that each person can maintain his/her own profile in XML, as I would want to enforce strong data validation. You can't write a DTD to check that someone enters their age as a number, or that you can't have a birthday on June 31st. To do this, you need to check imput data using something like Params::Validate, perhaps with Regexp::Common. If you go down the XML route for this, you have to use something complicated like XML Schema.

If you want to migrate your data to a different programming environment, you can easily convert your data to XML at that point using one of Perl's many XML modules such as XML::Simple.

er.. what's your question? if the size of the staff is to remain that small, the hash is probably fine. you could tie() it to a *DBM_File if you wanted to.

for larger data sets, a real database table might be optimal. your current format would make it easy to insert.

Since this is a prototype you're probably fine using a simple hash, but archon's suggestion to use a DBM or database is good advice if the project begins to expand. I think I'd be inclined to keep the variable length entries (i.e., skills) in an array though. It'll be cleaner to iterate over an array than to ensure properly formatted strings to split on commas upon retrieval.

So it's fine and perfectly okay to write:

     :
Katie => {
     age    => 24,
     :
     :
[download]

     :
Carl => {
     born    => '1978-04-01',
     :
     :
[download]

rdfield

Katie => {
  age    => 24,
  skills => [
    'perl', 'java', 'C', 'XML', 'MySQL', 'PHP', 'bioinformatics',
    'genetic programming', 'chemical analysis',
  ],
  phone  =>  '310.xxx.xxxx',
  email  =>  'xxx@xxx.xxx',
},
[download]

As has been suggested before, saving the data in XML would buy you a whole lot of data independence, extensibility, and functionality - you get built-in Xpath, searches, and data validation using XML modules.

You may encounter resistance based on ignorance, but I encourage you to learn XML if necessary - there is no down-side. Here is a sample based on your requirements:

<?xml version='1.0'?>
<AllEmployees>
  <emp name="Mike"  age    = '27'
     phone  = '213.xxx.xxxx'
     email  = 'xxx@xxx.xxx'>
     <skills>
       <computerlanguage name= "python" skilllevel='5'>
       <computerlanguage name= "java"   skilllevel='2'>
       <computerlanguage name= "python" skilllevel='5'>
       <speciality name='bioinformatics'>   
       <speciality name='biochemistry'>
     </skills>
   </emp>

   <emp name='Cindy' age='23' ....etc
    <skills>
      ...etc...
     </skills>
    </emp>
    ...etc

</AllEmployees>
[download]