4

I know that Salesforce is recommending to keep the number of child records in Master-Detail relationships (MDR) below 10.000 records.

In one situation I am heavily relying on Sharing being inherited in Master-Detail relationships so I plan to convert a Lookup with 100.000 child records to a MDR.

What will happen? Is the 10K a hard limit or what problems will occur?

  • Aren't you running into problems already? Because the Lookup Skew problem doesn't only occur with MasterDetail but also with lookups. developer.salesforce.com/blogs/engineering/2013/04/… – Folkert May 15 '17 at 9:26
  • 2
    I had a quick look and couldn't find anything around this, but I do know from personal experience is that access to the master record with ~50,000 records is severely impacted. After 50,000 performance was slow trying to do any DML at all in relation to this. This could be in relation to the 50k SOQL limit. I'm guessing though, we had to split it out. – Dan Jones May 15 '17 at 9:26
  • 1
    One limitation I've come across with that kind of relationship is that you can be prevented from deleting the master record(s) if the total number of records (parent and children) is more than 100K. You end up having to delete the children in batches, then the parents. – Aidan May 15 '17 at 14:27
3

A few issues

Deleting, updating rows, record locking

Deleting:

You can not delete more than 100k rows In a single Apex transaction, but wait it gets worse. This includes child rows that have been both deleted and removed from the recycle bin. You can instead delete all the lines first ensuring any lookups are nulled as you do, this does mean an update is needed before the delete which halves the allowed dml rows and if you want to empty them from the recycle bin you are looking at a third. Alternatively you can wait for the child records to be "hard deleted" by salesforce a process which can take a few days to kick in. I think you can also raise a case to get it done.

I have seen a parent record in a MD relationship being unable to be deleted for almost a week with people very confused as it seemed there were no related records left.

Updating rows:

We are obviously limited to 10k dml rows in a single Apex transaction so if you were wanting to have some logic done on the children in MD relationship any more than that and you have to start looking at splitting writes across asynchronous processes, but you are trading off transactional integrity. Which may not be an issue in your case.

Record locking:

This one might not be that useful but I find it interesting anyway. If you have lookups on those child lines that use the restrict delete (Don’t allow deletion of the lookup record that’s part of a lookup relationship) then SF is going to lock those related records when you create or update your child lines. This can mean that if you were wanting to perform parallel writes on rows that lookup to the same record there is a good chance you are going to hit a locking contention.

So if you are going to be dealing with volume 1) Don't set lookups to required (so they can be nulled) 2) Do not use (Don’t allow deletion of the lookup record that’s part of a lookup relationship) behaviour if you are wanting to support parallelisation. 3) If you were not after the sharing inheritance I would even go so far as to advise against MD if you are looking at a hierarchy of hundred of thousands to millions of rows. This is because of the performance cost at those volumes, I have even maintained my own rollups in the past.

| improve this answer | |
3

EDIT: This article goes in-depth to the 10K record problem: Account Data Skews

10K is not a hard limit, only best practice. However, you may see performance issues going above 10K. Much of this has to do with the calculation of who has what record access. You can read more about Salesforce recommendations (along with other recommendations to keep your instance performant) here.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.