Question

In an online ticketing system I’ve built, I need to add real-time analytical reporting on orders for my client.

Important order data is split over multiple tables (customers, orders, line_items, package_types, tickets). Each table contains additional data that is unimportant to any report my client may need.

I’m considering recording each order as a separate line item in a denormalized report table. I’m trying to figure out if this makes sense or not.

Generally, the queries I’m running for the report only have to join across two or three of the tables at a time. Each table has the appropriate indices added.

Does it make sense to compile all of the order data into one table that contains only the necessary columns for the reporting?

The application is built on Ruby on Rails 3 and the DB is Postgresql.

EDIT: The goal of this would be to render the data in the browser as fast as possible for the user.

Answer 1

depends on what your goal is. if you want to make the report outputs faster to display then that would certainly work. the trade off is that the data is somewhat maintained through batch updates. You could write a trigger that updates the table anytime a new record comes in to the base tables, but that could potentially add a lot of overhead.

Maybe a view instead of a new table is a better solution in this case?