Sometimes just because a thing is possible doesn’t make it a good idea. In the last week I have been helping a client whose web developer has dissapeared. The developer implemented the database using a variation on the Entity Attribute Value (EAV) modelling paradigm. The database consists of only four tables: Entities, Attributes, Values, EntityTypes. So the entities in the database don’t match any real-world entities – there is no products table for products, no categories table for categories and so on. This generic modelling approach might sound good but in practice it’s a real pain. Look at this query diagram representing a simple query to find out what categories exist in the database:
The query consists of numerous joins and is completely opaque. The EAV wikipedia article I referenced above contains a list of downsides to the EAV approach, with which I can only concur. For a new developer approach an EAV implementation its an uphill battle to understand what is going on. Writing queries is a cumbersome task, and the logic such as foreign key constraints that would normally reside in the database layer now needs to be implemented in the application codebase.
For me EAV is something I will be avoiding in any new developments I embark on…