Apex Code Development You need to sign in to do that
Don't have an account?
jhart "Storage Usage" calculation question
Our app uses "junction objects" to hold many-to-many relationships.
Many of these junction objects are defined to be very small: two master-detail relationships, plus a "BothIds" field which is a string that concatenates both IDs and is defined as a external ID to get uniqueness constraints (note - salesforce, conjoined key support for many-to-many relationships would be *very* helpful so we don't have to roll our own).
Plus, they have the required "Name" field which is always set to ".".
It seems to me these objects should be at most 100 bytes, and probably much less depending on how Salesforce stores the ID datatype.
However, by comparing object counts to the "Storage Usage" screen, it is clear that "Storage Usage" counts them as about 2,000 bytes apiece. This is consistent across orgs.
Is this 20x overhead purely for indexing? Is there something else going on?
Here's an example of an object type that exactly matches the above description:
Message Edited by jhart on 11-19-2008 12:44 PM
Many of these junction objects are defined to be very small: two master-detail relationships, plus a "BothIds" field which is a string that concatenates both IDs and is defined as a external ID to get uniqueness constraints (note - salesforce, conjoined key support for many-to-many relationships would be *very* helpful so we don't have to roll our own).
Plus, they have the required "Name" field which is always set to ".".
It seems to me these objects should be at most 100 bytes, and probably much less depending on how Salesforce stores the ID datatype.
However, by comparing object counts to the "Storage Usage" screen, it is clear that "Storage Usage" counts them as about 2,000 bytes apiece. This is consistent across orgs.
Is this 20x overhead purely for indexing? Is there something else going on?
Here's an example of an object type that exactly matches the above description:
Message Edited by jhart on 11-19-2008 12:44 PM
Werewolf,
Thanks. I do understand that Salesforce's underlying schema is one-row-per-field rather than one-column-per-field, but I find the 2KB minimum object size to be a bit steep regardless. My customers ask me about it sometimes, and I'd prefer a better answer than "salesforce's storage calculation is wacky".
So, I'd still like to hear an official word from Salesforce explaining this per-object usage charge in more detail - is it accurate, or does the storage calculation logic simply have a floor of 2KB/object?
The storage calculation isn't wacky in any way. One way to think about it is that you get 500 custom fields in total (whether you're using them or not -- that's the speed-vs-space thing). Now let's say there are 4 bytes per empty custom field. 500 * 4 = 2000 -- 2Kb!
The upshot of this is that in many cases Salesforce.com is actually undercounting storage. If you're using all 500 custom fields, you've probably got more than 4 bytes in each, but in most cases it still counts it as 2Kb. However, it all kind of averages out in the end.
You are implying that, if I used all 500 custom fields with a 32KB text string, I would still only be charged for 2K.
I do not believe this to be the case.
If salesforce wants to overallocate storage for its own internal reasons, that is fine. But it should not charge the end-user for the those internal reasons. If my objects are only 100 bytes, I should only be charged 100 bytes plus indexing overhead.
The end result is that many-to-many relationships are far more expensive than they should be, thus incenting developers to try to avoid them, thus incenting bad data models.
One of our AppExchange Apps has a fair number of many-to-many relationships. It is frustrating to see some paying customers uninstall our application because salesforce is radically overcounting the size of those objects (and salesforce charges extremely high rates for additional data storage).
If anything, junction objects should be free.
I recently came accross this problem when creating many-to-many relationships. It seems like this is just one of those annoying constraints of the platform in its current state.
I hope in the future this kind of relationship will be a less constrained, perhaps by making junction objects special lightweight objects that do not require as much space.
With that in mind, vote up my idea :D https://sites.secure.force.com/success/ideaView?id=08730000000gPAZAA2