0

We are running into a problem when querying and reporting performance is degrading due to having huge number of records on org of some specific custom objects.

Basically in our use case, we are not interested in old records, e.g. from previous years, but at the same time we cannot just remove them - due to some regulatory rules this information should be kept somewhere for a long period of time. So we've decided to try to use Big Objects for archival purposes.

There is no problem with moving old records of some specific custom object into corresponding Big Object. But the challenge for us here is that we need to archive objects which are in master-detail relationship. And unfortunately system does not support BigObject-to-BigObject lookup relationship. To make it tougher, child records also have bunch of attachments, which also should be archived.

So the question here would be - how could we archive such master-detail hierarchy of objects? Should we try to pack them into single big object with some sort of json serialiazation of child records and long text are fields to save this? Or is it better to create two separate big objects, but without configuring any relationships between them? And also how to archive attachments then, since big objects do not support them?

Any suggestions/ideas would be appreciated.

Improve this question

1 Answer 1

Reset to default
1

Archive master-detail relationship Custom Objects

What Exactly are Lookups and MasterDetail fields? They are just Candidate Key (Primary Key for some other table). If you can replicate the same behaviour via your data-model you can archive big objects

Create 2 Big Objects, Object Parent and Object Child for your master-detail relationship.

In the child, the object creates a field ParentID(18 digits) text which is Required and Index as 1.

Now you can get all children of a parent using the ParentId Index. Yes you cant use joins but hey, you can do an extra query to serve your purpose.

Attachments into Big Objects

Attachments are a binary, not flat table that can be stored in database(CLOB and BLOB data is not supported by Big Objects). There is Long text-area 131,072 characters where you can store Base64 string of file, but that will not allow you to store huge files. You have to look for a backup tool like OWNBackup, AWS S3 etc.

The purpose of Big Objects is to make Old Data available in SF to be accessed or used in SF as an when needed.

Due to some regulatory rules this information should be kept somewhere for a long period of time.

If you just need it for Regulatory Purpose, Own Backup or any backup solution serves the purpose.

Improve this answer
1
  • Agree with your thoughts re MD relationship, probably we will go that road. But regarding attachments, we still need them to be somehow accessible in SF and linkage to parent should be maintained. In other words, if we archived master-detail relationship as two big objects, attachments should be 'attached' in one form or another to child big object and sit in SF, since the whole 'archive' solution should follow single approach, i.e. either everything sit in SF, or everything migrates to some external system.
    – wesaw
    Commented Aug 20, 2019 at 13:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .