I am a student developer with Oregon State University's Business Solutions Group and I am currently working on a Salesforce integration project for one of the University's colleges. As you can imagine, the data we are working with is coming from several different places and in a variety of different formats. I was wondering if anyone with more experience in setting up Salesforce object schemas could talk about the pros and cons of relational database style normalization in Salesforce. What do we gain by not normalizing and using Record Types to categorize data? (For example: a Person-Account that encompasses Students and Faculty and uses Salesforce Record Types to differentiate between the two) What do we lose?
This message was inspired by this webpage: Salesforce Guru: Record Types
Notice that the first thing it advises is to not normalize (overmuch) because it prevents us from taking advantage of some built-in Salesforce functionality. Overall, the page seemed helpful, albeit incomplete.
The answer to this question seems critical to the success of our project and will help us to decide how to reorganize the data we are initially migrating to Salesforce and ultimately build our Salesforce object schema, so any thoughts, additional resources or advice are very much appreciated. Thanks!
The inspirational web page is correct. With the "standard objects" like Account, Contact, Case, Lead, etc. and even with custom objects the system works best to use fewer tables (objects) and segregate the data based on some value (such as record type).
By using record types you leverage the point-and-click UI. For example, for the Account object you have a default page layout. But for each record type you can have a unique page layout. Furthermore the security model uses record types to limit or grant access as appropriate to different user profiles.
As the author says SOQL is NOT SQL.