On Tue, Jun 16, 2009 at 01:21:42PM +0200, A B wrote: > > The examples you gave (i.e. shoe size, hair length) would fit normal > > table columns much better. > Sorry, shoe size was not a good example, think of it as <random > string> instead of shoe size. The data/name is nothing you can relate > to in any way or build special columns for or treat in other ways. It's this decision that makes me think you've backed yourself into a corner where EAV is your only solution. EAV is "nice" because it allows you express arbitrary parings between keys and values (i.e. it's a "map" of arbitrary size, like a hashtable in other languages) but it has its downsides in that all values are constrained to be of some specific type and it doesn't allow you to exploit the power/expressiveness of databases very easily. > > 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! That's not what I meant at all; I was meaning to group several related integer values into a single table. This would be a more natural fit for the example names you gave. 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. -- Sam http://samason.me.uk/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
