> The way you described the problem the EAV solution sounds like the best
> match--not sure if I'd use your synthetic keys though, they will save a
> bit of space on disk but queries will be much more complicated to write.
I guess I'll have to build procedures for all the complicated queries
when ever I add or remove an integer value.
> EAV style solutions are rarely good/easy to maintain when the problem
> changes so maybe you can take a step back from the problem and solve it
> some other way.
That's what I keep reading about EAV :-(
> 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.
> 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!
