On Tue, Jun 16, 2009 at 12:21 PM, A B<gentosaker@xxxxxxxxx> 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. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
