I have a couple of applications that use this mode. One is an app that handles specs for parts. Different part types have different specs and different types of tests. New part types don't get added often but this app was intended to replace multiple existing apps and the client wanted the flexibility to add a new part type on the fly without having all the associated programming to create new tables and forms and queries. The other was an app to manage contract documents for an Insurance application. Again, adding a new insurance product doesn't happen frequently although, since the company was a start up and they only offered a few types of products initially, they knew they wanted to expand this capability.
The advantage of the entity/attribute/value model in these cases was primarily that they eliminated all the programming that was required to define a new part type or a new insurance policy type. If you want to see some of it, I can post some images. I can't post the database though. Or, if you would like a demo, I can set up a meeting where I can walk you through all the moving parts. Once you see how it works, it is not very difficult. There is a master tale of attributes. All of the fixed attributes are defined normally in the Product table. Then there is a child table which houses all the attributes for this particular product type. When you add a new policy record, after the form saves the fixed information, it runs an append query to copy all the variables for this product type. Because the records have to be created before you enter data, validation becomes tricky so the "required" part can't happen until you try to use the variable. The insurance app was also connected to thousands of Word documents since the whole point of the app was to ensure that the data fields specified in the policy were always the same in all the various policy docs.
My insurance app was a godsend to the client. It was taking their IT people 3-6 months to create all the forms/reports/docs, etc to add a new product type. With my app, a user could do it without my help in a day or two. Then a little longer depending on how many Word docs needed to be created and mapped.
So, if I knew I needed to expand the universe of types, I would strongly consider the entity/attribute/value model but if the types were static and not likely to be expanded, I would stick with a more typically normalized schema. Seven types isn't a lot, especially with only 29 variable attributes. The thing to keep in mind if you use the model you started with is that ALL tables relate to the entity table, NEVER to the type tables. I think that may be where June's test tables got out of hand.
