Hi markos,
marcosc (5/19/2008)
I mean this: if the program and the reports all need to know the property name, it's the same thing as knowing the column name of the table. So I prefer the traditional design.Besides that, adding a column isn't something difficult, so we should not be lazy about that.
Besides that, you can use foreign keys when a column valus needs options (example: single, married, divorced, etc.). You can't do that with property-values pairs.
Besides that, you can be sure that a requiered value is present using a "not null" column. That's dificult to achieve with a property-value design.
Regards, Marcos.
You are right in this regard. I am not a fun of name value pair either. I am just sharing my experience and how I managed to get the system up and running without holding the project. I have never used name value pair design for this type of problem. EAV doesn't lend itself for this particular problem.