From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Storing questionnaire data |
Date: | 2008-10-23 18:01:13 |
Message-ID: | 20081023180113.GI2459@frubble.xen.chris-lamb.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Oct 22, 2008 at 03:59:07PM +0100, Thom Brown wrote:
> I have previously had a questionnaire which had 5 tables, questions
> and answers and question types, questionnaire and results.
This design looks a lot like the EAV (entity-attribute-value) style of
database design. This tends to be frowned upon here but is good in some
situations. I personally have tended to just go for a simple field per
question spread over several tables (if it's a big questionnaire). I.e.
something like:
CREATE TABLE questionnaire (
qnid SERIAL PRIMARY KEY,
entryname TEXT,
qndate DATE
);
CREATE TABLE questionnaire_page1 (
qnid INTEGER PRIMARY KEY REFERENCES questionnaire,
business_purpose TEXT,
average_turnover NUMERIC,
num_employees INTEGER
);
CREATE TABLE questionnaire_buildings (
qnid INTEGER REFERENCES questionnaire,
buildnum INTEGER,
PRIMARY KEY (qnid, buildnum),
buildingname TEXT,
buildingsize NUMERIC,
lightlevel INTEGER,
ventilation INTEGER
);
This way you can enforce useful constraints inside the database, but
requires the database to be aware of what questionnaire data you're
actually storing. The EAV style would, in my eyes, be appropriate if
you're trying to write a generic program that could handle arbitrary
questionnaire forms and not just one specific one.
Hope that helps
Sam
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-10-23 18:03:01 | Re: Import db from 8.1.3 to 8.3.1 |
Previous Message | Tom Lane | 2008-10-23 17:57:27 | Re: Postgres optimizer choosing wrong index |