[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