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 value column. "CHILD" with "PARENT_ID", "COLUMN_NAME", and "COLUMN_VALUE". Perform joins as you see fit to build up the structure at 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@xxxxxxxxxxxxxx on behalf of Jasen Betts Sent: Sat 20-Jun-09 12:14 AM To: pgsql-general@xxxxxxxxxxxxxx Subject: Re: Dynamic table On 2009-06-17, A B <gentosaker@xxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
