The cases in recent postings are much bigger than what I implemented so many years ago. I ran into problems pretty fast and in retrospect, my usage of the concept was extreme (and wrong). I suspect some of the bad reputation comes from similar cases! Even so, there are certainly issues and limitations with the model one needs to be aware off (referential integrity comes to mind).

My case used an EAV to store attributes known at design time. It could be done directly in tables with the consequence of adding entity specific triggers to implement cascading deletes for example (with properly working on delete set null etc.). Just as an explanation, cascading deletes still do not work well in SQL Server! We now have "on delete set null", but it is half baked implemented and supports just one such cascading relation case between two of the same entities. A simple thing such as keeping track of who did the creation of a record and who did the last update is already handicapped out of the box, even today!

There was also no uniformity in attribute value type and each type had its own table to store native values in (no use of sql_variant). During performance measurements back then, the most expensive operation was the number of joins required to build a complete record. And as you might guess, updating required transactions for even the simplest of updates and that across multiple tables....not exactly ideal. I went for it at the time because of initial development speed and the desired cascading behavior and unique ID of every record in the database....after that I never touched the idea again...obviously ;).

One downside of EAVs could be solved (and many more other things) by having a where clause on relations. Just as we eventually got filtered indexes and filtered statistics, we really need filtered foreign keys too (even basic checks on originating and target table would do). It is a much recurring wish by me and i suppose by anyone that is consistent in applying foreign key constraints.