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]

> efficiency.  Duplicating the kind of report you can write with a
> well-crafted SQL query using CDBI might take a lot of coding, and it
> would probably involve duplicating things that your database is really
> good at (set operations, for example) in perl code.

I interpret your argument in this way:  all things being equal and
accounted for ( ie requirements, specifications, design goals ), there
is no real gain by going through the trouble of writing a really
complex report through CDBI's api, just write the sql and be done with
it.   I agree.

Here is where I think CDBI is so great though.  If your work situation
is such that feature /scope creep is a constant since design goals and
specifications and all the other "niceties" that go into making stable
software only exist during blame-storming sessions after a crash and
burn.

Tying into your CDs example: imagine that we have that cd database,
which was created for tracking artist/cd information, but somehow our
real business is counting how many times a track has been played and
by whom....  Is it just me and the company I work for?

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")

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".

anyway, thanks for clarifying things for me,

james

        -- 
        .--- .- -- . ... -.-- --- ---