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/
