Apex Code Development You need to sign in to do that
Don't have an account?
HaroldH Account object data storage (and long-text field)
I'm trying to understand a bit about how objects (eg, Account, custom, etc) are allocated storage space.
For example, each time I create a new, mostly empty Account record, an additional 2KB is used, as reported in the Current Storage Usage report in Setup/Data Management/Storage Usage.
However, if I add 32KB of text into one of the Long Text Area fields on an Account record, no additional storage is indicated used in the Current Storage Usage report.
I'm working on an implementation that contains two very different "Account" types, and trying to decide whether to use the Account object with many custom fields and two record types (which would mean half of the fields in each type of Account would go unused), or whether to create a custom object for one of the account types. Data storage usage is just one consideration, but it's raised this question.
Any informed thoughts would be much appreciated.
For example, each time I create a new, mostly empty Account record, an additional 2KB is used, as reported in the Current Storage Usage report in Setup/Data Management/Storage Usage.
However, if I add 32KB of text into one of the Long Text Area fields on an Account record, no additional storage is indicated used in the Current Storage Usage report.
I'm working on an implementation that contains two very different "Account" types, and trying to decide whether to use the Account object with many custom fields and two record types (which would mean half of the fields in each type of Account would go unused), or whether to create a custom object for one of the account types. Data storage usage is just one consideration, but it's raised this question.
Any informed thoughts would be much appreciated.
How I think it works is like this:
Nearly every object in the system is considered to have used 2KB of space. The exceptions are Attachments, scontols and a few others. (If there's a 'sizeof' field visible in the API then it doesn't use the 2K rule). The presumptive reason for this is that it's very quick (and efficient) to get either the SUM(sizeof) for an object or COUNT(*) and multiply it by 2.
Where this fails miserably is many many of my records don't even approach 2K in size. I have a daemon that syncs the entire API-visible schema to a SQL server here. Our 130+MB of storage on SFDC gets boiled down to about 28MB on our SQL server.
In SFDC's defence there are several size calculations that are errored in our favor as well. I'm lothe to publicize them as I would not wish to encurage abuse but if anyone from SFDC would like to inquire in private I'll gladly let them know.