On Fri, Feb 15, 2008 at 9:56 AM, Balázs Klein <Balazs.Klein@t-online.hu> wrote:
> > given that answers for a questionnaire are stored as a
> > batch
>
> Not in our setup - for all sorts of reasons (preserving responses on a connection failure or restart, monitoring
responselatency in real time, creating adaptive/branching questionnaires) we send each response separately.
>
> > people running reports on will be the ones to notice, i.e. at
> > retrieval time.
>
> I am not sure - different responses are aggregated into different attributes in different ways - those properties
needto be retrieved during scoring/report generation, so being able to create a join directly on a response is a good
thingfor me. But report generation - in our case it must be a DTP quality PDF - is such a beast anyway that db times
dwarfcompared to pdf generation.
Also, if you need to you can probably add a slony machine to your
setup to run the reports on, and it doesn't matter how many reports
you run, your production system will only have to run the user
interfacing side. This allows for all kinds of optimizing indexing on
the reporting server that you might not want to have on the production
server.