Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: db schema modules, recommendations?

by jeroenes (Priest)
on Jul 10, 2001 at 00:36 UTC ( #95149=note: print w/ replies, xml ) Need Help??


in reply to 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?
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.

      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://95149]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (6)
As of 2014-11-28 07:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (193 votes), past polls