Updating it would be as simple as manipulating a normal array or hash. You'd have to add serialize/unserialize steps at the start and end of your program, but that's easy to do.

As the number of records increase, so will the memory usage. Of course, the hassle of updating a flat file increases with the current technique, so at some point you might consider a true database. (Somewhere after 100 or 150 records is my personal guideline.)

-- Randal L. Schwartz, Perl hacker

Here's a way to do it if your flatfile consists of one record per line, with whitespace before the "record number" at the end:

#!/usr/bin/perl -- -*-fundamental-*-

use strict;
use Fcntl qw(:flock);

## Set these as needed...
my $flatfile   = "flat.txt";
my $num2delete = "12";

my $result = &DeleteRecord($flatfile, $num2delete);
if ($result) {
  print "No records were deleted.\n";
}
else {
  print "Deleted record number $num2delete.\n";
}

exit;


sub DeleteRecord($$) {
  my $flatfile   = shift;
  my $num2delete = shift;

  ## Open the flatfile in read/write mode
  open(FLATFILE, "+< $flatfile") or die "Could not open $flatfile: $!\
+n";

  ## Lock it exclusively
  flock(FLATFILE, LOCK_EX) or die "Could not lock $flatfile: $!\n";

  ## Try and find a match
  my $found=0;
  while(<FLATFILE>) {
    last if /\s+$num2delete$/ and ++$found;
  }

  ## If no match, we clean up and return a 1
  unless ($found) {
    close(FLATFILE); ## Also unlocks for you
    return 1; ## Have the caller handle this case;
  }

  ## Mark the spot where the record to be deleted starts
  my $here = tell(FLATFILE) - length $_;

  ## Read in the rest of the file:
  my @slurp = <FLATFILE>;

  ## Rewind to the spot we marked earlier
  seek(FLATFILE,$here,0);

  ## Stick everything else back in, overwriting the file as we go:
  print FLATFILE @slurp;

  ## If we don't truncate, the last record will appear twice (think ab
+out it)
  truncate(FLATFILE, tell);

  ## Close and unlock, and return success to the caller
  close(FLATFILE);
  return 0;
}
[download]

Its one thing to toss data around in flat files. (In fact, appending to flat files is a great way to collect data for parsing.) But flat files are NOT data bases. There is a reason for fifty million variations of SQL DBs. If you are doing something that works like a database, by all means... use a data base!

Errrr, I didn't.

It is a matter of scale. If the amount of data is small and the database design is simple then why not?
Least ways you can spare yourself the great overhead (and often cost) of creating a SQL database and having to support it (I've seen so many sites where whole teams of DBA's were needed to support relatively simple databases)

For under 5000 records I'm not convinced that opening a database connection squirting your SQL across the TCP socket and getting a reply back is any quicker than scanning the file. Especially if your data set has no suitable keys. Having said all that I'm quite a fan of AnyDBM_File as well

Maybe I'm just an old disillusioned DBA :-)

"We are all prompted by the same motives, all deceived by the same fallacies, all animated by hope, obstructed by danger, entangled by desire, and seduced by pleasure." - Samuel Johnson

AgentM Systems nor Nasca Enterprises nor Bone::Easy is responsible for the comments made by AgentM.