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