This seems like a reasonable place for a module. One thing to note is that in your sample interface you're basically splitting the logic between the module and the calling code. That the caller controls opening and reading the file, pulling out a hash for each entry whose structure the caller must know in advance in order to read, indicates that this isn't a complete modularization of responsibilities.

To my mind, the clearest way to fix these issues is to go down the OO path, in which an instance of DBParser opens a file to read, controls iteration internally, and returns results that match your search criteria for you to print from the calling context or to pass to another module specifically for formatting output. Doing this gives a clean interface, separation of duties, and the ability to create further refined subclasses of both the parsing and printing components.

The difficult part in doing this will be specifying the search criteria since the data is pretty hairy, so it would be good to start with a review of all the ways current scripts access it, and see if there's a method to the madness that you can tease out and formalize.

---

"The dead do not recognize context" -- Kai, Lexx