[VPM] [RFC] naming a module for SQL routines

Peter Scott Peter at PSDT.com
Sat Sep 18 12:29:47 CDT 2004


At 12:04 AM 9/18/2004, Darren Duncan wrote:
>The main reason concerns a revisiting of one of the module's main 
>intended uses, which was to support the idea of any database-related 
>activity being representable by a SQL routine or imitation thereof. An 
>implementation of a SQL routine that my module 
>describes/models/defines could either be stored in a database schema 
>(eg: as a SQL stored procedure, function, or trigger), or it could be 
>stored on the client/application side (eg: as a fusion of Perl code 
>and DBI calls).  But from the application's point of view, the routine 
>simply exists in a locally addressable space and can be invoked more 
>or less like a Perl routine (function or procedure), regardless of 
>whether it is actually in the database or on the client.
>
>A routine is quite generic in scope and can hold complete instructions 
>for any kind of database activity, including arbitrarily complex 
>select queries, DML, schema creation or manipulation, user management, 
>transactions, and connections.  Therefore, saying that my module 
>supports or models routines means that it supports and models all 
>types of SQL.  It was also designed in the hindsight of SQL-2003, and 
>is not limited to SQL-1992.

This is a bit off the wall, but after giving this considerable thought, 
what comes to mind is SQL::Mechanize, after WWW::Mechanize.

>But while my module can represent SQL effectively, it is not exactly 
>the same as SQL, and can be used with both databases or applications 
>that don't want to talk SQL.  Hence, calling it a "SyntaxModel" is 
>somewhat archaic.

Given this, perhaps DBIx::Mechanize would be more appropriate.  YMMV.

-- 
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com/
*** New! *** http://www.perlmedic.com/



More information about the Victoria-pm mailing list