Do you have the time? This is probably the determining factor in most cases. If you have the time and it doesn't detract from your regular duties, why not? If not, we all know the old adage
"if it ain't broke . . . ".
Is the system used for modifying or appending data? Then you would probably want more sophisticated techniques. On the other hand, is it only used for manipulating data to generate reports or create batch update scripts? I have text-based Perl systems that do things like produce class rolls for entire departments, generate unix accounts/forms for multiple class sections and create site e-mail directories combining 6 or more separate hosts. Some of the data files like the /etc/passwd files are stored in colon delimited text files, others have fixed width fields. The point is, they are already in that format, some are downloaded regularly from our IBM mainframe. I don't update those files, I mine them. Some of these systems use as many as ten or twelve different files and undergo complex merges and sorts. The longest any of these programs runs is about 15 seconds tops with the average more like 5 seconds.
Any database system that is used regularly is going to increase in either size or complexity. That is when things start to slow down. My systems became more complex but the original data didn't grow in size. I created some perl modules to handle the data parsing, and stored complex data structures to disk (using MLDBM and Storable's nstore). These intermediate files are then used by other program further down the line and load quickly.
If time is not an issue, what have you got to lose? Make yourself more marketable by adding DBI, MySql, or Postgres to your resume!
If the code and the comments disagree, then both are probably wrong. -- Norm Schryer
In reply to Re: Text Database
by jlongino
in thread Text Database
by EyesOnly
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |