Tuesday, December 13, 2011

Entity Attribute Value

let's talk about the problem.  Attributes are an independent group of modifiers for any entity.  Bit each entity does not have all the same attributes, and we want to cover the general case. One thing that helps is the 80/20 rule, 80% of the attribute set will be the same, it is the residual 20% that bothers.  TE can suppkly atribute models for the common cases:

Schema1:(attribute structure, entity_rec1,entity_rec2,...),
Schema2:(attribute structure, entity_rec5,entity_rec6,...)

 We have an enclosed block of all entities and their values that satisfy the identified schema; each entity record includes is enclosed values for the attribute schema. Then we have another set of entities that use another attribute schema. So TE allows us to ties a particular attribute format to a particular set of entities, that helps.  But the table much be rewritten if any attribute is added to any entity, because the pointer field have to be redone.  This is equivalent to crating an intermediate, square  table from an entity list, which is what SQL normally does to prep a query on variable entity schemes.

I suspect nested order methods gets us half way to general attributes.  It is a slightly different method than the one used by Google, call row/col mangling.  Google recognizes that the number of possible entity/attribute arrangments is much larger than the actual used. So they have a way of indexing on the fewer possibilities, rather than all of them.

However, I think nested order helps a lot by grouping values, attributes and  schema all together within forward pointing syntax, I think.

No comments: