A lookup (with Delete this record also) and master-detail share a large number of similarities:
- Deletion of the related record causes a cascade delete that does not invoke triggers.
- Both types of relationships are automatically indexed.
There are some trivial differences:
- Lookups are not required by default, where master-details are always required. Lookups can however be made required to share this behavior.
And there are some potentially major differences:
- Lookups do not support rollup summary fields (although there are community solutions available).
- Detail records do not have an owner, and thus do not have an ownerId field.
- Detail records cannot independently participate in sharing, the access to them is always controlled by the access level (require read vs write to edit detail records) set when defining the relationship. Records related via lookups have wholly independent sharing from the related record.
- Master-detail relationships cannot be to an object of the same type (e.g. MyObj_c to MyObj_c).
- You can have no more than 3 levels of master-detail relationships, meaning a parent, child, and grandchild object. On the other hand you can built almost infinitely complex networks of lookup relationships.
- There can be no more than two master-detail relationships on a object, and the first of the two has special behavior:
The first master-detail relationship you create on your junction object becomes the primary relationship. This affects the following for the junction object records:
- Look and feel: The junction object's detail and edit pages use the color and any associated icon of the primary master object.
- Record ownership: The junction object records inherit the value of the Owner field from their associated primary master record. Because objects on the detail side of a relationship do not have a visible Owner field, this is only relevant if you later delete both master-detail relationships on your junction object.
- Division: If your organization uses divisions to segment data, the junction object records inherit their division from their associated primary master record. Similar to the record ownership, this is only relevant if you later delete both master-detail relationships.
In the end which to select often comes down to how you want to impact your sharing and security model. Lookups allow much greater flexibility here, but often this will require code and apex managed sharing to make full use of, although it can be leveraged with sharing rules.
There are four different kind of relationships in the force.com platform.
But I like to categorize them in a slightly different way than the help pages:
- Lookup
- Master-Detail
- Hierarchy
- Standard relationships
There are lot's of help topics and articles on Lookup and Master-Detail, such as the relationship overview and the relationship considerations topics in help. I don't like including Many-to-Many in this kind of discussion because, for all intents and purposes M:M is just an implementation of two M-D relationships (by strict reading of the docs), or possibly two lookup relationships or a mix of the two.
To dispense quickly with hierarchy relationships, these are a special lookup self-join relationship on the User object. Read up on those on your own. :-)
So let me talk about my own invented fourth category.
Standard Relationships
If we (salesforce.com) provide you with a relationship between two objects, that is a standard relationship. Not lookup, not master-detail. Why do I bother providing this fourth category? Because it is the easiest way to stop people trying to categorize them as either lookup or master-detail when they often share characteristics of both. When you approach working with any standard relationship the question you really need to answer is, "how does this standard relationship behave." Frequently standard relationships have characteristics that you just can't do with a custom relationship. Ever tried to make a custom relationship polymorphic? Go ahead...give it a try. You will fail. But there are many examples of polymorphic standard relationships.
I like to categorize these in their own separate place independent of lookup/master-detail. In fact, anything standard follows the same rule: it behaves exactly the way that salesforce.com wants it to behave to fit the particular purpose of that standard thing.
In my opinion, the Account-Contact relationship is a perfect justification for this fourth category: it is a little like lookup, a little like Master-Detail, but fundamentally behaves the way it does because we decided it should.
That might not be the "proper" way, as you ask, but it is the one that makes the most sense to me.
Best Answer
They are a unique category of fields commonly referred to as standard lookup fields. Unlike custom lookup fields, they have the generally have the "cascade deletion" property set to true, and unlike custom master-detail fields, they may have the "always required" property set to false. Also, these fields can restrict deletion of accounts when certain conditions are met. To learn their special properties, refer to Help for any particular field.
EDIT:
It's now possible to enable custom lookup cascade deletion, which has a similar behavior to how Accounts/Contacts, Account/Cases, and Account/Opportunities behave, but without the ability to restrict deletion when certain criteria are met. You can read this Knowledge Article for more information.