From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | A B <gentosaker(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Dynamic table |
Date: | 2009-06-16 11:59:19 |
Message-ID: | 407d949e0906160459p397ee931v982ea9d6fe61380@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Jun 16, 2009 at 12:21 PM, A B<gentosaker(at)gmail(dot)com> wrote:
>
>> Just had a quick flick through your previous posts; and I'd probably
>> stick with the multiple tables approach. It's the most natural fit to
>> relational databases and until you know more about the problem (i.e.
>> you've experienced the data your going to be getting and the ways it's
>> going to change) you can't do much better.
>
> One table per integer is one way that I have not thought about. Thanks!
you said you wanted to quickly select all the values for a given user.
That does not jibe well with having to use a separate table for each
integer.
I don't think think it's fair to call this EAV actually. It sounds
like the integers are a collection of things which represent the same
thing. Ie, they're all bank balances or all distances driven, just for
different time periods. Storing all objects representing the same
thing in the same column is just a regular normalized table, not EAV.
You might want to consider partitioning the table of integers by type
to facilitate dropping the old ones. But that's an administrative
trick, not a fundamental schema design decision.
From | Date | Subject | |
---|---|---|---|
Next Message | A B | 2009-06-16 12:56:53 | Re: Dynamic table |
Previous Message | Whit Armstrong | 2009-06-16 11:52:45 | Re: pg_relation_size, relation does not exist |