If you are looking for some working example, why not look at the everything core (see also link at the bottom of this webpage)? Or slashdot's?

By 'single file', do you mean single perl file? Why be obsessed with a single file? It's the functionality/ modularity that counts, not whether you can cram it in one file.

It probably is a good idea to hide an interface from your own core, as long as you do it in such a way that you don't force unhappy constructs in the calling code.

I personally think that a lot of the database management stuff you mention are just the problems that are solved by the RDBMs. If you don't like MySQL's solutions, try eg postgres or oracle etc etc.

Hope this helps, and good luck with your coding!

Jeroen
"We are not alone"(FZ)
Updated

My apologies for the vagueness.

To be more specific: I would like to be able to express the structure of my database in such a way that column attributes, relationships, etc. are neatly packaged in a single module (or combination of configuration file and module) with an API that will allow me to simplify the design of any code that has to deal with the database. I've already accomplished this to some extent with my DB module, but if someone else with more SQL mojo (just about anyone with any level of SQL experience, at this point) has already been down this road and made their work available via the CPAN, I'd like to look at what they've done.

Granted, other dbms's would probably allow me to solve some of these problems without as much effort, but I don't have a choice about the dbms at the moment.

I'll give The Everything Engine a look. I'm sure I can learn a thing or two (thousand) there, but I wanted to make sure I wasn't missing anything on CPAN before I started digging code out of another project.

I'm curious just why you want to write the database design in perl.

I'd write that in SQL with the CREATE commands, and just update that SQL and rerun when something needs to be adapted. Unless you routinely have to change the database structure, than you're better off with controlling these things in perl. I have only experience with writing the basic structure once and after that expanding it occasionally.

Is there something in your application that calls for a dynamic database structure?

For example, backing up. I have a cron job that runs Postgres' pg_dump to dump all data in my database and saves it on another server. That doesn't include the blobs, and so I have a separate perlscript that dumps all blobs and puts them in a tgz that is transferred to the other server. There is a script available that can restore the blobs may the need arise. These are just some bashscripts, whith perl doing the more difficult tricks. The perlscript could also have been written in bash and sql, but perl is the more elegant glue in this case.

Thanks everyone, for the input. Rather than spend any more time searching, I'm going to dig into the module I've already written, clean up the code, and spend some time meditating on ways to use it to get closer to my goal. I may regret not having put more effort into this issue later on, but I don't want to linger over this problem any longer.

converter

However, in the interest of completeness there is a module called something like DBIx::TableAdaptor::MySQL (Adapter?) written by Michael Granger at one time (not posted to the CPAN, though I think that was on his todo list) which offered a clever solution to referential integrity with MySQL.

He built table adapters for both MySQL and Oracle which supported a variety of additional features (e.g., the Oracle table adapter built relational objects based on Oracle's data dictionary - no configuration file needed).

Michael is one of the best Perl coders I've ever met, and very friendly to boot. I'd suggest dropping him a line.

I also have another unrelated suggestion: Be forceful and push your agenda if you have not already done so. Don't let someone tell you you can't install this or that module that you need for your work. The CPAN is all about not reinventing the wheel, and if someone tells you that you or the SA can't install a particular CPAN module, it's usually just to dissuade those who aren't serious about what they're doing. Convince them that you're serious and know what you're doing and that you really need the module in question.

Hope this helps :-)

Thank you for the tip. I chased down Michael's site, and the code is available from here, but it looks like it's on the back burner for now.