Re: please give examples of where using cdbi to produce comlex report queries is truly a bad idea

[prev] [thread] [next] [Date index for 2005/03/06]

.--- .- -- . ... wrote:
> Abstracting out the database into a manageable and stable set  of
> classes is WAY easier to maintain and customize than a ginormous query
> that keeps growing and changing over time... (read: append if/else
> conditional to end of query for new "tweak")

Well, I generally disagree.  SQL is a very high-level declarative 
language, and is pretty easy to modify, tune, etc.  Doing the same thing 
with plain Class::DBI methods will be more work for any non-trivial 
query.  What Class::DBI is good at is saving you all the repetitive code 
you would have to write when doing simple read/write work on a bunch of 
tables.

> Of course, my notion of a "report" may be a little different, since
> our database is so hyper-normalized that  to get any data point
> requires traversing a minimum of 3-4 tables, this makes most queries
> "report-esque'" (ie uses aggregate functions, groupings, etc).  I
> pretty much consider every screen in our application a "report".

If you find yourself having to do lots of set_sql stuff, or using TEMP 
fields for something that comes from the database, or writing set 
operations (grouping, counting, etc.) in perl, you may be doing things 
the hard way.

- Perrin