> 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! -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
