Storing computed data

I'm new to database use and design and have a design dilemma.

I am building a database of events. The database will be added to by a batch process once a day but otherwise it will be read only and will be used to extract various bits and pieces of information about the events, e.g. "all type A events followed within a half hour by a type B event from the same source, with no earlier type B events from this source". I haven't done so yet, but I imagine one can construct complicated queries/joins to find this sort of thing dynamically, but I am wondering if it might not be better to create some auxilliary tables of e.g. a table of event sources with info about first, last event from that source, stuff like that, and actually store it in the database. Is this considered in bad taste? Are query/join optimizers good enough that this sort of in-database caches are not normally used? Of course these aux tables will need to be rebuilt when new data is added, but I'm thinking that's not too bad since that will only happen once day. What do y'all think?