You seem to be suggesting that different entries may have different numbers of fields to be entered. How is the true field count determined for a given entry, and where to the field labels come from? (In your example, there are just two fields per entry, with the labels "id" and "comments".)

You also seem to want the user to be able to write incomplete entries, escaping out of the field-entry loop with only one or more of the initial fields filled in, and one or more of the final fields in the sequence left undefined (null), and these get written to the database file along with complete entries.

I think what you might want here is a subroutine that takes two array refs, one containing the field labels and the other containing prompt strings, with both arrays ordered according to the desired sequence for user input; the sub would return a hash with field labels as keys and user input as values. Whatever is returned by the sub can then be written to the database. Something like this (not tested):

sub entry_prompter
{
    my ( $labels, $prompts ) = @_;
    my %entry;
    for my $i ( 0 .. $#$labels ) {
        my $user_input = prompt $$prompts[$i], -escape;
        last if ( $user_input eq "\e" );
        $entry{$$labels[$i]} = $user_input;
    }
    return %entry;
}
[download]

WIth that, it's up to the caller to set up the appropriate arrays, handle the iteration that prompts for "Add another entry? y/n: ", and read/write the database file.

If I were you, I'd add another array that provides conditions for sanity checks on the fields, so that the "entry_prompter()" sub can test $user_input -- e.g. should be numeric, or "y/n", or not longer than 10 characters, or whatever.

Then again, if I were you, I'd use a real database (not a flat file), and I'd use Tk; to provide a nice GUI with appropriate user input widgets to fully populate a record as efficiently and reliably as possible, along with a "Submit" button.

(updated to simplify some of the wording in the text)