Re: design question

William Robertson wrote:

> No offence, but option A is not only an astonishingly terrible idea,
> but a well known astonishingly terrible idea. It's actually one of the
> classic astonishingly terrible ideas. For example, see
> http://oracle-wtf.blogspot.com/2006/02/eav-returns-concrete-elephant-approach.html

Oh nice. I was not the first with this problem ;) But this link describes B as an "improvement" of A. Thus both A and B are bad?

> What if you want all rows containing both "Hello" and "Foo"? What if
> you want unique or foreign key constraints?

Ok, these are complex queries.

> It's a fact of life that
> unconstrained data gathers incorrect values as time goes on.

OK.

> My advice would always be to do the data
> modelling properly and design an interface such that the model is
> separate from the client application and presentation logic.

This would mean at least one table for each type of object, doesn't it? Received on Mon Sep 08 2008 - 08:14:55 CDT