Why would anyone use a Perl script, to back up a PostgreSQL production server, to a MySQL backup?
It's just an example. Most people only use one database type (though there are exceptions, and even scenarios just like the one described above; people do all sorts of things in the real world). But even when you're using just a single database, the particular, single set of database-specific behaviors you're invoking are delegeted to Rose::DB by Rose::DB::Object. That's the division of labor between the two modules that I was trying to illustrate.
How are you going to handle DBI_DSN, DBI_USER & DBI_PASS? Ancillary: How are you going to fit your hash into an environment variable (or 3)?
I covered that at the end of the last post: "since a serialized format does actually have its uses (e.g., when stored in a file or sent over a network connection), DBI could support one or more of the standard formats that can be used to serialize a Perl hash into a string: JSON, YAML, Data::Dumper, etc." Add to the examples "...or when stored in environment variables." User/pass could be kept as separate parameters or could be incorporated into the hash.
In reply to Re^10: Avoiding compound data in software and system design
by siracusa
in thread Avoiding compound data in software and system design
by metaperl
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |