I would suggest using a database rather than a text file. It will be much faster and more manageable as this grows.
If you are unable to switch this to a database, you still have a very workable alternative. Since you are using formats to print the data to the file, it should be relatively easy for you to convert it into a comma separated file. Then you can use Text::CSV to manipulate CSV fields. You can then read in the file in update mode, change the appropriate data and write it back out.
Better yet, if you cannot use a database, switch it to a CSV file and use DBD::CSV to execute SQL statements against a CSV file. Very handy. Then, if you switch it to a database later on, you should have minimal changes to the code.
Cheers,
Ovid | [reply] |
If for some reason, you can not use a database (which although
the program specification may not call for shared addressbooks
and stuff like that, trust me, it will change, and you will
need a database... program specifications do that...) then
my suggestion is as follows:
My suggestion, is that you use the CPAN module MLDBM. What
this module alows you to do is store complex data structures
within a DBM without you having to deal with all of the
complexities of serialization and unserialization. Where
I in your situation I would do something like, each entry
into the addressbook is a hash: my $entry = { NAME => "eduardo arino",
PHONE => "(555) 555-1212",
ADDRESS => "666 Dante Circle, Murfreesboro, TN",
EMAIL => "ed@NO_SMAP.home.com" };
and then, index the hash that is the tied MLDBM DB file
by whatever it is you wanted, name, phone, address, whatever.
Being that you could access it like a hash, your data manipulation
problems would be greatly minimized, and being that this
is not a speed critical piece of code, the overhead in the
MLDBM package would probably not kill you...
then again, there might be some other way of doign it... it's
just that whenever i hear people talk of using flat files, I
get this feeling that it's going to end up coming back to
haunt them... I know the few times i have, it did...
| [reply]
[d/l] |
OTOH, the program specification could include, or change to include, use of ASCII data files. The nice thing about not using a database when you data is just ASCII, is that you can read it, edit it, port it, etc., without needing to change your program. That is, the users of the program have access to their data. As this is something to be stored in ~, it seems better to use ASCII. Browsing my own ~/.* files, this seems to be pretty standardized.
Paris Sinclair | 4a75737420416e6f74686572
pariss@efn.org | 205065726c204861636b6572
I wear my Geek Code on my finger.
| [reply] |
very very very true... i am a BIG fan of ascii files for
configuration information... however, data files, i like
making it difficult for people to edit them by hand... i
have discovered that if you make datafiles easy to edit by
hand, the "users" will most likely hurt the file format
and cause your program to die... (i remember once someone
edited a datafile by hand, and it caused a race condition
that brought down a Sun E450... that was painful...) so,
i guess, once again, the point becomes: "what are they
asking you to do, what will they ask you to do? use the
right tool for the right job."
| [reply] |
A database seems like overkill in this case. It's hard to answer your question without seeing some code, but here is basically the way you do it. To edit an entry, your program will have to read in the entire file and store it
in memory (probably an array), then search through the
array for the correct entry. Once it is found, make the changes. Finally, reopen the file for writing, and dump
the newly changed array into the file. This is a very general answer for a general question. Specific questions
will yield more specific answers. :)
| [reply] |