There a lot of debates about how to store custom fields in database. Here is some interesting links that help me to get decision (in my case is EVA solution :-))
Storing Custom Fields in the Database (see also comments) - http://blog.springframework.com/arjen/archives/2008/01/24/storing-custom-fields-in-the-database/
Thread from forum - http://osdir.com/ml/bug-tracking.bugzilla.devel/2005-01/msg00191.html
Guide to the EAV (FAD) - http://weblogs.sqlteam.com/davidm/articles/12117.aspx
http://en.wikipedia.org/wiki/Entity-Attribute-Value_model
The circumstances where you would need to go beyond standard row-modeling to EAV are listed below:
- The data types of individual attributes varies (as seen with clinical findings).
- The categories of data are numerous, growing or fluctuating, but the number of instances (records/rows) within each category is very small. Here, with conventional modeling, the database’s Entity-Relationship Diagram might have hundreds of tables, with the tables containing thousands/ millions of rows/instances emphasized visually to the same extent as those with very few rows; the latter are candidates for EAV.
This situation arises in ontology-modeling environments, where categories ("classes") must often be created on the fly, and some classes are often eliminated in subsequent cycles of prototyping.
- Certain ("hybrid*) classes have some attributes that are non-sparse (present in all or most instances), while other attributes are highly variable and sparse. The latter are suitable for EAV modeling. classes are seen in business database applications. For example, descriptions of products made by a conglomerate corporation depend on the product category, e.g., the attributes necessary to describe a brand of light bulb are quite different from those required to describe a medical imaging device, but both have common attributes such as packaging unit and per-item cost.
Comments