in reply to Class::DBI and data split multiple tables

It's difficult to follow what you're describing here. Are you saying that depending on which date range is being searched, a different table name and schema should be used? If so, load them all up as separate Class::DBI classes and choose which one to run the search against in your CGI. If this isn't what you meant, maybe you could show us an example of the SQL you would write to do this by hand?
  • Comment on Re: Class::DBI and data split multiple tables

Replies are listed 'Best First'.
Re^2: Class::DBI and data split multiple tables
by kor (Initiate) on Mar 20, 2007 at 20:19 UTC
    >>Are you saying that depending on which date range is being searched, a different table name and schema should be used? thank you for the reply

    Yes exactly, it will most often be multiple tables selected from, not just one. Somtimes it will be multiple years (schemas)

    >>If so, load them all up as separate Class::DBI classes and choose which one to run the search against in your CGI.

    Well they'll likely be searching a range not a singular date. Find transactions from Dec 3 2006 -> jan 3 2007 where this this and this but not this. etc Off the cuff sql like:

    (select date, conn_id, cust_id from 2007.jan_trans where date in ( '20 +07-1-3' ) and cust_id=3) UNION ALL (select date, conn_id, cust_id from 2006.dec_trans where date in ( '20 +06-12-3') and cust_id=3 )

    And actually more often it will probably be about 1-6 month ranges.

    So that's what I'm struggling to figure out how to do in Class::DBI. I'm trying to avoid all the normal manual sql work etc.

    thanks

      You have a couple of options. You could make your code smart enough to call multiple Class::DBI classes and add up the results in perl. Or, you could make your database hide this complexity. Using views would do it, or some kind of partitioning like MySQL 5.1 supports.

      You could also do your own SQL generation, but Class::DBI will be useless to you then. In general, Class::DBI is not good for reporting queries. It's really more useful for manipulating individual database rows.