Localized storage and retrieval
The first technique—application handling of string joins and splits—is certainly the most self-contained. This leads us into a small digression.
Self-containment can be beneficial, as it tends to concentrate the logic of a script internally, making things slightly more simple to understand. Unfortunately, this localization can also be a real pain. Take our megalithic database as a good example. In the previous section, we wrote four different Perl scripts to handle the four main data manipulation operations. With localized logic, you’re essentially implementing the same storing and extraction code in four different places.
Furthermore, if you decide to change the format of the data, you need to keep four different scripts in sync. Given that it’s also likely that you’ll add more scripts to perform more specific functions (such as generating web pages) with the appropriate megalithic data from the database, that gives your database more points of potential failure and inevitable corruption.
Getting back to the point, we can fairly simply store complex data in
a DBM file by using
either join( )
,
to create a delimited string, or pack( )
,
to make a fixed-length record. join( ) can be used
in the following way to produce the desired effect:
### Insert some data rows $database{'Callanish I'} = join( ':', 'Callanish I', 'Callanish, Western Isles', 'NB 213 330', 'Stone Circle', 'Description of Callanish I' ); $database{'Avebury'} = join( ':', 'Avebury', ...