function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Thomas StrohThomas Stroh 

Database Design & Best Practices

Hello,

 

I was hoping to start a discussion on best practices for database design inside SFDC. As a simple example, say I would like to add an unlimited number of "Custom" fields to the existing "Account" object. I see (2)  potential ways to accomplish this task ...

 

Option #1 - Create "Custom" object with a lookup relationship to Account. This would allow for unlimited "custom" objects related to Account.


Option #2 - Create fields Custom1, Custom2, Custom3, etc. within the Account object.

 

 

My current design has already implemented Option #1, which seems like the appropriate database design. But now that the solution is released into production and I have tens and thousands of "Custom" rows now in the system, I find that this new Object is taking up all of my disk space for my current Org.

 

I've discovered that each "row" in SFDC takes up 2 kb worth of data. It doesn't matter if I have 5 fields or 250 fields ... takes 2 kb. So now I'm second guessing myself on the database design. To be honest, I never even thought of option #2, which is my mind is bad database design. But now that I'm dealing with disk space issues and might have to continue paying for more disk space ... Option #2 looks like a better option.


Anyway, looking for other comments/opinions on this subject.

 

Regards,

Thomas

 

Pradeep_NavatarPradeep_Navatar
Option #2 seems to be more appropriate. In my opinion creating a seperate custom object just to keep additional custom fields is not a best practice. We should always keep the additional fields in to the related object. You will save the disk space and overhead on queries. You will also feel comfortable at the time of migrating the data.
Thomas StrohThomas Stroh

Thanks for the input. I replied to another post that talks about for Force.com platform and database size issues. Please see http://community.salesforce.com/sforce/board/message?board.id=general_development&message.id=39486#M39486

 

The main issue is that the force.com is not a good platform when deal with lots of data. We are told directly by SFDC that their system can't handle terrabytes of data and that we would need an archiving or normalization strategy.