I'm looking at a design specification of a work request object that would if implemented purely as a standard salesforce object would cause very sparse columns requiring tens of recordtypes and hundreds of heterogeneous hidden fields.
http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model
I'm considering Abstracting out many of the sparse fields into child attribute-value records to be creating by deep cloning 'template' entries and viewed and updated by custom VF pages.
I should be able to correctly assign types the attribute values by giving the the AV object multiple record-types for which the correctly typed value field is the only one visible.
Has anyone tried this EAV approach on SFDC? Or have any suggestions on how to manage this sort of complexity otherwise?
Attribution to: Baxter
Possible Suggestion/Solution #1
Baxter, I think the thing to keep in mind is that SOQL (and the database ORM) within the APEX API are relatively limited interms of the scale of their permissible operations.
RecordTyping, Parent-Child Relationships make complex database hierarchies more manageable but not as dynamic as other available database engines.
That being said, I can't implemented an incredibly complex database structures on SFDC and SOQL.
I do know however, that parent-child relationships can only be queried in 1 depth lower (Collect all related records on that lookup to the parent). That maybe a limiting factor in a complex structure.
Also, consider if your going to have literally hundreds of relationships in a sparse table model, that there is no programatic way to manipulate the structure of your database. You can build objects out of meta-data xml and port them into an org, but you'll have to write a custom program to construct this XML.
Attribution to: jordan.baucke
Possible Suggestion/Solution #2
I haven't tried this approach with Salesforce, but the biggest concern I'd have would be storage. Salesforce has a simplistic storage calculation where custom object records take up 2 kb each. If you went with an EAV approach, you'd be using up 2 kb for each of the sparse fields. Storage in Salesforce is expensive, so I'd probably prefer to use custom fields. This would also allow you to use standard page layouts and other point and click portions of Salesforce.
Attribution to: Daniel Hoechst
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/680