Lookup Vs Master-Detail Relationship
There comes a moment when we are confused about whether to create a lookup relationship or a master-detail relationship between two objects (can be a Standard or a Custom object).
Below are some use cases for the aforementioned relationships.
A master-detail is useful for the following points:
1. We want the record to exist in the system only if its parent exists. For instance, if we have two objects, say, Contact and ContactDetail. Here, I would like to have contact details only if the contact is present in the system. That is if we have a contact holding all the professional as well as personal details in the system then if contact account is deleted, it doesn’t make sense to keep contact details. This can cause inconsistent behavior.
2. If we want a child record to derive the sharing setting of a parent record, then a master-detail relationship is the one that we need.
In the above example, the user will always need to have access to contact detail record along with the parent Contact record. Here it is good to have a master-detail relationship.
3. In addition to the above, another goal to opt Master-detail is when we want a parent mandatory for a child to exist in a system. Although this can be achieved by a validation rule in case of a lookup, this makes it effortless as no extra stuff is needed to make the parent required for a child. A child object will have this parent record as a required field in a custom object as well as on the record layout. The master-detail design does not allow us to remove it from the layout.
A lookup is useful for the following points:
1. We want the record to exist in the system even if its parent does not exist. For instance, if we have two objects say, Employee and Designation. Here, I would like to have the designation list even if the employee has been removed from the system. As soon as I delete the Employee, the designation record remains there in the system.
2. If we want a child record to have the sharing setting different from a parent record, then a lookup relationship is beneficial.
For example, suppose we have an employee accommodating a specific salary structure. Here an employee should be able to see only the structure assigned to him, not the one assigned to a different user. This is the perfect case for a lookup relationship.
3. If we need to relate two different objects optionally, then a lookup is the only option. For example, there are three objects: Student, University and College. A student can be registered directly at a university as well as in a specific college affiliated by the university. In this scenario, a lookup relationship is the only option. The reason being, the student can either be enrolled in a university or a college.