Reporting webpages

I will soon be tasked with re-vamping a reporting page where users will be able to build their own reports to pull data from their database. My question to you is this: how would _you_ _actually_ build reports dynamically for users?

I want to know how YOU would actually do it, because I have Damien's book, and I have been to MST's talks. I know how THEY would do it. I want to know how other 'in the trench' programmers would do it.

The interface is static, where they can select checkboxes to bring in more data, fill in date range fields. The selection of data is actually pretty mundane, except that a checkbox means that I want all rows of type 'X' where 'X' actually has a number of conditions attached. In the end it isn't that difficult of a concept, except it isn't trivial enough for simple DBIx::Class abstractions.


Well, I'd probably use Fey, but I'm biased ;)

Seriously, I think Fey is very well suited to this task. It's all about dynamically building complex SQL queries.

I don't know that an ORM is terribly useful for this sort of stuff, since reports tend to cross class boundaries a lot more than a typical CRUD app.

I agree with Dave here. Don't use an ORM for reporting. Most of the time reports deal with aggregate data, not individual rows. For that SQL really shines so use a good tool to generate SQL like SQL::Abstract or Fey. I've also used Rose::DB::Object::QueryBuilder with good success.

When I have a reporting nail, I always seem to use a Stored Procedure hammer, if the RDBMS is sufficiently competent.

About this Entry

This page contains a single entry by leonard published on July 9, 2010 9:50 AM.

Weekend/free time was the previous entry in this blog.

perl golf is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.