I congratulate you on being organized. For small apps, it's good.. for large apps, it's invaluable.

You seem to be using a 2 layer system. But until you flush out the details, I won't say much more on what exactly you are doing. I'm more of the MVC system - model, view, controller. Your model layer would be all your db interfaces (selectUsers(...), updateUser(...)). Your view would take the output and render it somehow. Your controller ties the two, taking care of input/output manipulation and choices.

For your database stuff, you have your DB.pm, which is good. In the case you switch or want to use other DBs, you can swap this layer out with ease, keeping a consistent interace.

For my controler, I would take the input and tarnslate it into XML documents. XML is very portable. Not the uber most efficent way in terms of CPU cycles, but what you lose in performance, you gain in great modulariztion.

Using XSLT, you can then translate into PDF, HTML, WAP, CSV, TXT, since your XML document is a complete description of your data.

---

For the model/DB stuff, you have little choice but to use DBI + perl. There are other ways, but DBI is prolly the most standard.

For the controler/decision making portion and the XSLT translation, there's a great tutorial at perl-xml.sourceforge.net

---

There are many arguments against much of this.

XML is slow to process - prototype your system. Using XML would be idiotic to do IPC between threads. The native forms are faster. Using it between systems is quite smart, especially foreign ones, ala web-services. In complex systems, it is also "good". Translating XML to any other formats is quite easy. Translating doc to applewrite format would be a pain. If the speed difference is negligible, I would go with an XML based solution.

XSLT is slow - Many web browsers support XSLT translation on the client end. It would be a matter of giving the XML and XSLT to the browser. For repeditive stuff, such as perlmonks comments, which have a definite pattern, the XML would be sent all the time as really small packets, but the XSLT once. Think of XSLT like CSS.

XML/XSLT are bloated. - mod_gzip is your friend. XML compresses quite well. Also, if you transmit the XSLT once and different XML packets using the same XSLT, you may not even need mod gzip since XSLT would be the work horse.

MVC is slower - MVC may be slower, but you reap the same benefits as you do from writting modules and functions and calling them. Yes, you have the overhead of a stack, but then again, if you want efficiency, you can always use ASM

---

MVC and XML/XSLT aren't the only ways. You can always do 2 or even 1 layer systems. Sometimes they are better since a project can be really REALLY tiny. XML/XSLT may be too slow for your system if you are working on an 8mhz machine, an embeded device or on a heavily loaded machine with no money to buy another. It's all a matter of choices and architecting what's best for your situation, monitarily and for current and future development.