in reply to Handling near-redundant SQL queries

I have a module that will construct an SQL query given the following:

It does so by doing the following:

Usage is something like:

my $sql = $builder->build_sql( select => [ "foo.column AS blah", "foo.column2 AS blah2", "bar.column AS bar", ], where => [ "foo.column3 = ?", "bar.column2 = ?", ], params => [ 3, 5, ], ); ## This would generate something like: SELECT foo.column AS blah ,foo.column2 AS blah2 ,bar.column AS bar FROM foo JOIN table1 ON (foo.foo = table1.foo) JOIN bar ON (table1.bar = bar.bar) WHERE foo.column3 = ? AND bar.column2 = ?

Additionally, if you have selectively denormalized your schema for speed purposes, this algorithm would take that into account. (I have, because it's a readonly reporting database. Other possibilities would be for an OLTP database that uses triggers to maintain certain denormalizations.)

Is this something that would solve your problem? I haven't released it yet, but could in a week or two. (I planned on doing so anyways, but could do so as early as the end of next week ...)

Note: This module doesn't do anything with the database. It's actually a text manipulation module that has some graph theory in the backend. So, it's completely RDBMS-agnostic. And, as you can tell, it produces SQL99-compliant queries. It also supports OUTER JOINs, if needed. I use this module to construct queries for both Oracle9i and MySQL 4.1.x.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Replies are listed 'Best First'.
Re^2: Handling near-redundant SQL queries
by simonm (Vicar) on Sep 01, 2004 at 22:23 UTC
    I have a module that will construct an SQL query given the following...

    I took a similar approach in DBIx::SQLEngine, which accepts a very flexible set of arguments and can both generate SQL or optionally execute it for you.

    When working at this higher level, the OP may find that they don't need as many subroutines -- for example, rather than having subroutines for each version of a select query based on which columns you need, your get_person_companies() subroutine could take a list of additional columns to include in the results.