No one likes to jump between multiple systems to do their job. With the growing number of applications used by businesses, it's more important than ever to share data across applications and consolidate in one place for you to use. This is why we have invested heavily in making it easy for business professionals to bring external data into our low-code app development platform, QuickBase, where they can tap the data by building consolidated reports and plugging it in automated workflows managed in QuickBase.
Once you have identified the data you want to bring in, how do you determine the best way to replicate the data so it meets your business needs? This blog post discusses two common data replication methods and guides you in selecting the right method for your use case.
How you replicate your data has a significant impact on how it can be utilized. In many of the cases we have come across, there are two major ways businesses want their data replicated:
The method you choose impacts the end state of your data, and you might find scenarios where you need one or both. To get a better grasp on the differences between the two, let’s look at a fictional company that sells subscriptions for a software-as-a-service product. Each month, the marketing department places the company’s customers into segments, which are used to target customers in marketing campaigns. Below is the marketing segment data for February 2016.
This segment data is valuable and has uses all over the organization, but how the data is used can differ from use case to use case, below are some example use cases that use the different replication methods noted above.
Let’s say a customer service manager, in the previously mentioned SaaS company, wants to start loading customer segment data into the CRM system her team already uses. By doing so, her team of customer service reps can use the CRM to look up a customer’s segment. The customer service reps can use this information to tailor their response to the customer. For this case, the team only needs the latest segment data for a customer, so making an exact copy of the table that stores the customer’s segment information makes sense.
For our next scenario, let’s move from the customer service department to the finance department. In Finance, there is an analyst that would like to use marketing’s segment data to feed a new chart on a dashboard that the senior executives use to monitor the health of the business. The chart monitors the monthly revenue for each customer segment over time, like the chart below.
In the analyst’s case, he isn’t only interested in the latest and greatest data, he is also interested in data from previous months. The problem is the marketing data is updated monthly and does not retain the previous month’s data. So the analyst would be better served by using a “Keep Everything” method of replication, which will copy and retain snapshots of the data as it is updated over time, so his data can retain all the historical information needed for him to generate the chart.
You’ll notice for each scenario, we also have different key fields assigned for the replicated data. Key fields are something you will need to be mindful of when choosing a replication method. For Match Exactly replications, the source data and replicated data should have the same key. For Keep Everything, the keys may differ from the source data and replication data. In our example, we were tracking the data by the additional dimension of time (month), so we needed to make sure that the replicated data accounted for time in the key field so that each record is unique.
You can see that the way you replicate data has a big impact on the end state of the data. Which in turn, determines how the data can be used. At QuickBase, we believe in providing users with as much flexibility as possible. In this spirit, our built-in no-code data integration capability, QuickBase Sync, enables customers to replicate their data either way.