• 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.