It is important to consider your customers' storage needs and use cases around their data creation and consumption patterns early in the application design phase. This ensures that your object schema is the most optimum one with respect to large data volumes, data migration processes (inbound and outbound), and storage cost. In this chapter, we will extend the Custom Objects in the FormulaForce application as we explore how the platform stores and manages data. We will also explore the difference between your applications operational data and configuration data and the benefits of using Custom Metadata Types for configuration management and deployment.
You will obtain a good understanding of the types of storage provided, and how the costs associated with each are calculated. It is also important to understand the options that are available when it comes to reusing or attempting to mirror the Standard Objects such as Account, Opportunity, or Product, which extend the discussion further into license cost considerations. You will also become aware of the options for standard and custom indexes over your application data, which will lead to the topic of handling large data volumes, covered in an entire chapter later in this book. Finally, we will gain some insight into new platform features for consuming external data storage from within the platform.
In this chapter, we will cover the following topics:
- Mapping out end user storage requirements
- Understanding the different storage types
- Record identification, uniqueness, and auto numbering
- Record relationships
- Reusing existing Standard Objects
- Applying external IDs and unique fields
- Importing and exporting application data
- Options for replicating and archiving data
- External data sources
During the initial requirements and design phase of your application, the best practice is to create user categorizations known as personas. Personas consider the users' typical skills, needs, and objectives. From this information, you should also start to extrapolate their data requirements, such as the data they are responsible for creating (either directly or indirectly, by running processes), and what data they need to consume (reporting). Once you have done this, try to provide an estimate of the number of records that they will create and/or consume per month.
For example, in our FormulaForce application, it is likely that managers will create and consume data, whereas race strategists will mostly consume a lot of data. Administrators will also want to manage your application's configuration data. Finally, there will likely be a background process in the application, generating a lot of data, such as the process that records race data from the cars and drivers during the qualification stages and the race itself, such as sector (a designated portion of the track) times.
Tip
You may want to capture your conclusions regarding personas and data requirements in a spreadsheet along with some formulas that help predict data storage requirements (discussed later in this chapter). This will help in the future as you discuss your application with Salesforce during the AppExchange listing process, and will be a useful tool during the Sales cycle as prospective customers wish to know how to budget their storage costs with your application installed.