1

According to an earlier question on SFSE & SF knowledge article, on record sizes, most objects in salesforce occupy around 2KB of storage space irrespective of what is stored in them. This basically means that If I have a custom object which stores additional data on say a 'Lead object' , I will be using 2x amount the space occupied by all Lead records. Is that assumption correct?

I believe this impacts the design considerations for any app. Even if the data is logically separate it would make more sense to add additional fields to the 'Lead' object to be within the storage limits. However, this would also lead to polluting objects with unnecessary fields.

What I understand from this is, if you have to choose between storing data in a standard object vs logically separating data into custom objects, the former is the optimal way so as to not exceed data store limits. Am I correct here?

Improve this question

1 Answer 1

Reset to default
2

Yes, if every lead record had exactly one custom object record associated to it, you would then be using 4KB per lead record. For a one-to-one correlation of data, it usually makes sense to put the custom fields on the object they belong to, in the interest of saving storage space. You should prefer custom objects only when it absolutely makes sense. Not only do custom objects cost storage, custom fields also don't count against the org's custom fields limit for an object if the app is an ISV app (e.g. security-reviewed and listed on the AppExchange). In other words, custom fields are literally free of storage requirements for an ISV app, while custom objects will always use 2KB per record.

Custom objects make sense when you either end up creating multiple fields for the same type of data (e.g. Location1__c, Location2__c, Location3__c...), or when a single piece of data can be associated to many different records (e.g. if you wanted to deduplicate emails by associating records together, you might create a custom object so you can track records with the same email).

Improve this answer
4
  • 1
    Just to add, If you find yourself making fields like Location1__c, Location2__c, .... Location10__c then it is time to use a custom object in most cases. Also good info on storage costs: salesforce.stackexchange.com/questions/14174/…
    – Eric
    Commented Mar 2, 2017 at 19:35
  • 1
    @Eric I edited in something to that effect.
    – sfdcfox ♦
    Commented Mar 2, 2017 at 19:38
  • @sdfcfox, eric, thanks, makes sense. How do you suggest storing transient objects (like custom logs) related to a Lead object. These logs would get deleted after a certain period of time. Do you recommend storing it in giant blob on the Lead object vs creating multiple custom log objects related to a Lead object?
    – gerad26
    Commented Mar 2, 2017 at 19:43
  • @gerad26 For custom logs, it probably makes sense to use a child custom object; I presume you might want to actually be able to report on the logs. As long as you're cleaning up after yourself, the actual storage cost should be negligible.
    – sfdcfox ♦
    Commented Mar 2, 2017 at 20:15

You must log in to answer this question.

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