Then, your Private:: idea is about the best you're going to get. SQL::Catalog might be of some service.
Frankly, it might even be best to store your queries in the database itself and pre-load them when the app starts up. *shrugs*
Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
I shouldn't have to say this, but any code, unless otherwise stated, is untested
| [reply] |
Frankly, it might even be best to store your queries in the database itself and pre-load them when the app starts up. *shrugs*
But if you do that - make sure that you actually keep the source to that information in operating system files, preferably under source control. Have the SQL specialist edit these files and load them to the data server as needed (and after thorough testing, of course).
Michael
| [reply] |
Use Class::DBI. It will save you enough time on the mundane create/update/search/retrieve logic that you can put more time into this customizable requirement.
While it will set up defaults for standard create/update/delete/search and *-to-* relationships, you have the ability to change the SQL wherever you see fit.
Class::DBI provides many ways to create your own constructors and custom SQL statements. Read Class::DBI -- Defining SQL Statements to learn more about this functionality.
| [reply] |