EAV is a fix for a very specific problem. It is not a good way to store all data, but it is a good way to extend the logical structure of a table without modifying the table itself. In our data design the only attributes that are kept in the EAV structure are non-critical atributes that are often optional, in that all entities of the table do not necissarily have that attribute. For example we have a person table that stores info about people, we use an EAV table to store attributes like phone numbers (varying number of them for a person) or email addresses, things like that. All of the critical data re a person is in the person table itself or in another related child table.

Using EAV as a universal storage structure is not, IMO, a good idea. But EAV sure does help when you need it.


>Hi!
>I faced with what I found common problems of this approach.
>First is slower data retrieval. Ok, I can cache all data using some class (collection of entities each of them is collection of attributes). This way data access if very fast while read data to cahce and dump cache to disk seems to run in seconds even with thousands of entities.
>
>Second problem is that there are no available mechanisms (IMHO at least for VFP) to query EAV data, to validate it, to protect uniqueness, reference integrity, etc. Creating such mechanisms looks like crating new DBMS from scratch. Googling on this topic I found that meny developers tried EAV but abadoned it because of this problems.
>
>In fact, I need a to create a data storage for system which must allow continious development which forces frequent changes to data schemes and even more - dynamic definition of some data schemes based on configuration data.
>So, I'm still in question to continue developing EAV engine for VFP or to choose another concept.