On Fri, Feb 15, 2008 at 9:56 AM, Balázs Klein <[EMAIL PROTECTED]> 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 response latency 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 need to be retrieved during
> scoring/report generation, so being able to create a join directly on a
> response is a good thing for me. But report generation - in our case it must
> be a DTP quality PDF - is such a beast anyway that db times dwarf compared 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.
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
