The concern with you A2 approach (the EAV-style approach), is that it tends to quickly degenerate into an unmanageable scale. As in everything ends up being modeled into the Entity-Attribute-value tables, so querying for complex criteria becomes a perofrmance and scalability disaster. Try taking on a query like "find me all long term (5-years or more) customers whose name starts with 'A', live in Delaware and have had 5 or more orders over 500$ in the last three months" in one of those pure EAV scenarios, and you quickly discover just how big of a mess you've created for yourself. Or - try to enforce relational integrity (or any form of data constraint for that matter) on any attribute in an EAV model.

The best approach IMO is a blended approach: build out using a traditional relational model whatever parts of your model you KNOW, and capture the oops'es using EAV as an interim step, WHILE you build out the changes to your longer-term stable model. A1 tends to leverage the strengths of the relational model, so should be the long-term answer for most things; A2 might have some flexibility, but loses a lot of features inherent to relational approaches and tends to invite performance and reliability issues.