in reply to Poor Person's Database

Designing a Search Engine on perl.com from April. The article deals with exactly what you're asking.

Using flat files is usually the painful consequence of a direct order from above. I agree with the above posts on DBM files. One concern I might point out about using multiple files instead of few large ones is that your operating system will waste a good deal of space due to minimum file size.

Replies are listed 'Best First'.
Re (tilly) 2: Poor Person's Database
by tilly (Archbishop) on Jun 20, 2001 at 18:09 UTC
    That was definitely a relevant article. I had never before noticed Search::Dict. That said, as soon as I looked at Search::Dict I found a bug and realized that the API should allow you to send in a comparison function rather than just assume that its two flags cover all cases people will see. But still it is a nice thing to know about.

    Bonus marks to the next person who spots the bug. (Yeah, real text files won't tend to hit it, but still I think core modules should get this kind of thing right...)

[reply]
      Well, there's a bug where if the search is trying to return the last line in the file, and there's no newline, it'll chop the last character off. Did you mean something else?
[reply]
        I actually meant something else.

        That specific bug is only going to bite if you had a search string that was the whole line and also was the last line in a file without a return. Similarly if $/ is set to a multi-line delimiter (eg \r\n because you are reading a DOS file in Linux) and the string you are looking for happens to include a tab right where a shorter entry has the \r, you may wind up with an incorrect location. (\r comes after \t, but no character should come before \t.)

        But look more carefully, there is another bug lurking in that code aside from the use of chop where chomp is a better fit.

[reply]

In Section Seekers of Perl Wisdom