Re: dynamic crosstab

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: Balázs Klein <Balazs(dot)Klein(at)t-online(dot)hu>
Cc: "Erik Jones" <erik(at)myemma(dot)com>, "Tino Wildenhain" <tino(at)wildenhain(dot)de>, pgsql-general(at)postgresql(dot)org
Subject: Re: dynamic crosstab
Date: 2008-02-15 21:14:16
Message-ID: dcc563d10802151314o96719d4o1494df4ea7bc70de@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Feb 15, 2008 at 9:56 AM, Balázs Klein <Balazs(dot)Klein(at)t-online(dot)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 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.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message James B. Byrne 2008-02-15 21:31:27 Re: Approaches for Lookup values (codes) in OLTP application
Previous Message Colin Wetherbee 2008-02-15 21:06:58 Re: PostgreSQL 8.3 on Debian, Ubuntu