I think you 'll find that it practice a relational approach (whether using nullable columns, or extra tables for each group of columns that would otherwise be nullable, or a mixture of those two) makes enhancement much less complex that and ERM-based structure. It is generally rather easier to control growth of storage in a relational system too.

If you are adding new information you have to change the application, whatever model you are using. You can get away, in an EAV model, without changing the database schema, but that's at the cost of giving the application a rather low-level interface to the database which actually entails a lot of additional application complexity. Inventing a new attribute in EAV is much the same as adding a column to a table (or adding a new table), but the complexity of providing for efficient search on that attribute is generally trivial in the relational system and a total nightmare in the EAV system, and all that extra complexity is thrown into the application, which is probably written in a language not designed for wrting efficient manipulation of masses of data instead of being implemented mostly in a database language in which this sort of thing is easy. That's just one of the areas in which EAV requires much more coding change for each enhancement than a proper relational model with a clean application/database interface woild ever require. And your A2 is raw EAV, likely to deliver a system which is amazingly expensive to upgrade and even more difficult to obtain decent performance in the face of upgrades.

Then there's storage. Each value for each attribute in the system you describe carries an identifier for the attribute and an encoding of the attribute's data type as well as the attribute's value. That is only going to be efficient when attributes are generally defined only for a small number of entities, and in that case you will much the same saving out of using sparse columns or having seprate tables for nullable groups that would otherwise be sparse. If the attribute is defined for more than a small fraction of the individual entities, the EAV model will take up more space than a relational approach.

So basically I agree with Matt that you will do more from the point of view of performance and flexibility for future enhancement if you eschew EAV and stick within the relational model.

I don't want to appear to speak for Jeff (he' much better than I am at SQL stuff) but I suspect that by "durability" he meant "not often having to tear up a lot of it up and start again to achieve enhancements" and by "history" he was simply referring to the requirement to have history that allows you to show what happened when. Regulatory requirements here mean we have to have a minimum of 6 years detailed history of personnel data such as pay and taxes deducted, and if they are significantly different in the states I'll have to ask som epeople why they've been claiming the US government imposes even more stronger regulatory requirements than does the UK gov. That's a pain in both relational and EAV models, and if its like everything else it'll be a bigger pain in EAV than in relational.