Isn't a many-to-one relationship the classic example of a child table?
Have one parent table that assigns a primary key. "PARENT" with "PARENT_ID". Have a child table that has a name and
valuecolumn. "CHILD" with "PARENT_ID", "COLUMN_NAME", and "COLUMN_VALUE". Perform joins as you see fit to build up the
structureat times. Use arrays if you'd like or perform multiple joins, which ever.
Matthew Hartman
Programmer/Analyst
Information Management
Kingston General Hospital, ICP
(613) 544-2631 x4294
________________________________
From: pgsql-general-owner@postgresql.org on behalf of Jasen Betts
Sent: Sat 20-Jun-09 12:14 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Dynamic table
On 2009-06-17, A B <gentosaker@gmail.com> wrote:
>> Your problem is currently sounding very much like an exam question; you
>> seem to be arbitrarily making decisions without showing any real data.
>> When you deal with real problems in the real world you're normally
>> making compromises when you model things and hence the decisions
>> wouldn't be as forced as you're making it. Design is about picking and
>> choosing between compromises and without knowing what the choices are
>> you can't design anything, this is one of the problems with tests.
>
> I wish it was just an exam question....
>
> Show real data?
> Well here it is:
>
> customer | value1 | value2 | value3|
> 1 5 3 4
> 2 8 2 10
>
> I hope you can believe me when I say that the names
> value1,value2,value3 really are impossible to relate. I will not
> decide upon those. Someone else is going to do that in the future. I
> just have to make a structure that can handle all cases from "shoe
> size" to "number of atoms in persons body" (well, perhaps I can say
> that the values will be in the 0...100 range, but that's about it.
> There is really nothing else I know about how the system will be used
> by other people. :-( I just know that I have to make them enter data
> like this since it is a third party that need this kind of data.
>
><confession>yes I took some random values for the "real data" since I
> don't know anything else about the data. </confession>
I like the table-per-column approach
And also the array approach, arrays of numbers of the sizes you discuss
are much faster than hard disks
what sorts of querys will be most common
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general