2 ms·
> rather than the EAV monstrosity you proposed. :) I would really like to know what is monstrous in the "Entity–attribute–value" model, I scanned the Wikipedia
by gbog 15y ago
> rather than the EAV monstrosity you proposed. :)
I would really like to know what is monstrous in the "Entity–attribute–value" model, I scanned the Wikipedia article without finding any obvious problems.
I had, however, many many problems with separate columns for each values: I have to handle tables with over 600 columns, for example "fixed_phone", "fixed_phone_modified", "fixed_phone_modified_by", "cell_phone", "cell_phone_modified", "cell_phone_modified_by", etc. With an EAV variant, I'll have "entity", "attribute", "value", "modified", "modified_by", "deleted", and it will be much cleaner, or prove me wrong.
- empthought 15y agoAll of those modification times/users should be in a separate audit trail table, which likely will look like an EAV table. That's OK because it's tracking the history of updates, e.g. (time, table_name, column_name, old_value, new_value, changed_by). The current (rather than historical) values should not be in generic EAV tables because putting data of different domains in the same column subverts both the relational model and the DBMS's indexing capabilities. If the point is to label telephone numbers with a role, then a person_id, phone_number, phone_number_label table should be fine.