I have a philosophical issue with SQL Phrasebooks in general. This may have to do with the types of applications I tend to write, so please take me with a grain of salt.
My applications tend to have a DBI wrapper that provides two pieces of functionality: 1) Business-level functions for accessing datastores (databases and other stuff) 2) Functionality for generating SQL on the fly, using somewhat complex graph theory The first is for things like "Given this username and password, can the person log in?". The second is for reports. My reports aren't your grandma's reports - you have a list of options to choose from and the app figures out what SQL to run from there, including all the table joins. So, what need do I have for a phrasebook? I can understand, to some degree, putting the statements from the first grouping into a phrasebook, but they're already behind a layer of abstraction and in one place. So, doesn't that mean I've satisfied the benefits of a phrasebook? Rob On Apr 9, 2005 11:41 AM, Terrence Brannon <[EMAIL PROTECTED]> wrote: > > > What is a SQL Phrasebook? > A Perl module which separates SQL from your Perl code, making it > accessible via a unique piece of keyed text. Think of it as > Locale::KeyedText for relational databases. > > Why would I need a SQL Phrasebook > * Better software engineering > Good software is designed in a DWIM fashion, where you spend time > doing what you mean as opposed to making repeated DWIS efforts. Any > large software project should not spend time defining sql in a > scalar and then accessing that scalar. This clutters your core code, > making it harder to follow, among other things. These tools provide > support for creating a separate library. > > * Knowledge of tables accessed > It is important to know what tables are being accessed in your > project. This is important for numerous reasons. First, for > statistical purposes, highly accessed tables might need tuning. > Having all of your SQL in one place and having your code base > searchable for a single label simplifies the process of > understanding how your code is accessing tables. Second, if a table > changes, you need to know which SQL was using that table. Having all > the SQL in one place makes it easy to handle table changes. > > * Testing > It is much easier to run model tests if all of your SQL is accessed > in the same fashion. It is also easier to group the tests by concept > if they can all be accessed via a unique label, e.g.: > > my @auth_sql = qw/USER_ON_ID ROLE_FOR_ID PERMS_FOR_ID/; > my @order_sql = qw/ORDERS_TO_DATE ORDERS_THIS_MONTH/; > > * Tuning > If a database expert can stare at all of the SQL for a project in > one place, it makes it easier for her to decide how to restructure > the entire SQL set.... or even more exciting, he might create > several SQL sets for different purposes and the Perl programmer can > haul in the appropriate SQL set tuned for his task, all without > modifying the Perl code! > > * Reuse > You drop your SQL in the library once, use as many times as you want > > List of SQL Phrasebooks > * SQL::Catalog by Terrence Brannon > * Class::Phrasebook::SQL by Rani Pinchuk > * Data::Phrasebook by Barbie > * DBIx::Librarian by Jason May > * SQL::Library by Doug Gorley > > Modules with a larger purpose > * DBIx::SQLEngine by Matthew Simon Ryan Cavaletto > * Class::DBI/Ima::DBI > * DBIx::Recordset > > ERRATA > This file is > > <http://www.metaperl.com/article-pod/Catalog-sql_phrasebooks> > > AUTHOR > Terrence Brannon, [EMAIL PROTECTED] > > -- > Carter's Compass: I know I'm on the right track when, > by deleting something, I'm adding functionality. > > _______________________________________________ > sw-design mailing list > [email protected] > http://metaperl.com/cgi-bin/mailman/listinfo/sw-design > _______________________________________________ sw-design mailing list [email protected] http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
