Total Pageviews

Friday, November 4, 2011

Why is the selection between Lookup and Master-detail relationship so crucial

Today as I was surfing through questions in the SF community , I came across a query which was related to the summary functions between two object linked with a lookup relationship. The query was simple all the respondent wanted to know was for:-
1. Two objects A and B linked with  lookup relationship how to find out the count of the object B linked to object A.
2. Also if it was possible to find sum of a particular currency field in B for all the instances of B linked to a particular instance of  A.
3. To do the same through configurations rather than any code
Some pro-s may say come on that is not possible for a "lookup" relationship!!! True  to achieve that one either :-
1. Needs to link the two objects with what we call the "Master-Detail" relationship.
2. Else if that is not feasible one may seek the intervention of code and a good old trigger will do the trick.
So very correct but this brings up the more basic question of :-
1. Planning - A product or project should be planned and designed very carefully and should undergo many iterations of brain storming before it actually goes under the hammer-specially when its ERD and database schema is being finalized.
2. Mapping of Objects and the relationships between them should be accorded utmost scrutiny and logical evaluation.
I remember during my early days with salesforce and managed package (remember it freezes the schema and makes any change very difficult and exhaustive process from the point of view of product maintenance) a small slip in the selection between a lookup and master-detail relationship compelled me to write a trigger which could otherwise would have been easily achieved with standard configurations.
Hence the time devoted to database design or in simpler terms "of deciding the way objects are linked with one-another" may appear irrelevant to some but its worth the trouble and will spare us from product maintenance nightmares.

No comments:

Post a Comment