Support for Entity Attribute Value tables (International CAB)

Tmicheli-Oracle

• Detail : A feature in which the entity-attribute-value model is built-in to the standard table. The e-a-v is a new type of column where the attribute name is stored in metadata, and could be different for different rows.
• Comment:
  • –Maybe partitioning data by data type specified for Attribute row.
  • –Improved performance
  • –Ability to paralyze
  • –Would not break storage model.
• Drivers :
  • –Several Key application rely on storing information in EAV structures and developers see as a must have.  Other options be to store this type of information in a different data store, which defeats one home for related data.
  • – Unified platform, common security model, consistent approach.
• Issues:
  • §  • Performance
  • §  • Ability to go through large numbers of EAV' attributes fast.
  • §  • Remove the need to store data in customer format in generic types.  Better optimization make data usable by Oracle.

Tmicheli-Oracle

We, Oracle are working on our internal process as to how to evaluate and prioritize the IDEAS submitted.  But the more votes obviously the more priority we will put on the request.  However votes/popularity alone will not determine the priority.

As we move through the process the IDEA will change stages: (not in flow order)

- Active

- Already Offered

- Archived

- Coming Soon

- For Future Consideration

- in Progress

- Partially Implemented

- Under Review

BPeaslandDBA

I voted this down. Every time I see a EAV implementation, performance it terrible. And normally, the EAV type of table was created because someone was too lazy to implement a proper data model.  Just my thoughts on it...

William Robertson

I agree with Brian. There are many well-documented conceptual and practical problems with EAV, including inflexible reporting, poor performance and lack of constraints, and so unless some game-changing transparent EAV-to-relational technology could be somehow invented, it will always be a terrible idea that Oracle should not encourage.

Niels Hecker

I think this could be easily modeled by using an object type with an attribute "Name" of type VARCHAR2 and an attribute "Val" of type AnyData. Furtheron also an nested table of such object types can be stored in one record.