in reply to Building a hash of employees.

Storing data in XML could be a good option as well. That way the future transition/expansion would be easy. The file can be maintained by non-perl people as well. Each person for example, can maintain his/her own profile in XML (given DTD) and you can integrate that data for your application.

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;

artist

Replies are listed 'Best First'.
Re: Re: Building a hash of employees.
by tomhukins (Curate) on Jul 02, 2003 at 22:02 UTC

    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.