Re: db schema modules, recommendations?

You are a bit vague in your question. I'll just give it a shot.

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

Comment on Re: db schema modules, recommendations?

Replies are listed 'Best First'.
Re: Re: db schema modules, recommendations? by converter (Priest) on Jul 10, 2001 at 01:09 UTC
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.	[reply]
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.	[reply]


good chemistry is complicated, and a little bit messy -LW
	PerlMonks