Conrad Lender wrote:
> I didn't intend any disrespect to Joe Celko. I have read a number of his
> articles, which tend to be well written and informative. Last year, when
> I posted to comp.databases asking for advice on whether to refactor that
> table, he wrote "You will have to throw it all out and start over with a
> relational design", "Throw away the idiot who did the EAV. This is not a
> good design -- in fact, it is not a design at all", and "This is basic
> stuff!!" Then he copied the same EAV example that was linked earlier by
> Rodrigo, claiming that "someone like me" had suggested it. With all the
> respect I have for Mr. Celko, that was hardly helpful, as that example
> and the situation I had described were quite different. It also did not
> encourage me to follow his advice and start from scratch (and fire my
> boss, who was the mentioned "idiot").
If we fired every boss who actually is an idiot there would be about half the
number of bosses.
All kidding aside, why is the boss specifying a database architecture? That
is not the boss's job.
> I understand the problems that can arise from bad design choices, and I
> know that Celko is vehemently opposed to anything that resembles EAV,
For good reasons.
> but I felt that in our case "throwing it all away" would be excessive.
Perhaps not. I had a situation some years ago where a supervisor would not
let me normalize a database and consequently the project nearly failed.
Fortunately, the company assigned a new team lead/project manager who did the
normalization or it would have been a disaster. Trying to make a bad approach
work is often, if not always, more expensive than replacing it with a good
approach.
> We had safeguards to ensure referential integrity, and keeping the
> values in the same table allowed us to let users manage them all with
> the same form. So I guess it's like Stefan Keller said in a different
> thread today: "Know when to break the rules."
Managing all the values in the same form is not intrinsically connected to
whether one stores the values in an EAV layout.
Telling oneself that one should know when to break the rules is not the same
as knowing when to break the rules. They are the rules for good reason.
All I'm saying is that EAV is a very problematic approach. I've been on
projects that tried to use it, and while that didn't make me an expert on the
matter by any means, it gave me some cause to trust Mr. Celko's opinion on the
matter.
--
Lew
