in reply to Re: db schema modules, recommendations?
in thread db schema modules, recommendations?

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.

  • Comment on Re: Re: db schema modules, recommendations?

Replies are listed 'Best First'.
Re:{3} db schema modules, recommendations?
by jeroenes (Priest) on Jul 10, 2001 at 12:11 UTC
    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.