What is Static Data? A new perspective

Databases are complex. Most discussions about databases are around how to scale. We ask questions like should you shard or index.

Databases are used for more than warehousing large amounts of data. Many applications store application reference data alongside customer runtime data. This seems sensible at first glance because you:

  1. Get data from one place
  2. Can reuse database design techniques across all the schemas you create

What’s an example?

Dynamic Data

Table Customers with CustomerId OrderCount CountryId

If you’re lucky, this will be a table with thousands of entries, growing rapidly. How rapidly are we talking about? You would expect 100/day.

Dynamic data is normally business critical. If you lose a purchase order, you could lose a customer. If you lose too many customers, you lose your business. It is incredibly important to manage dynamic data well.

The only way to recreate dynamic data is to go back to the source. Call your customers. Ask them what they ordered. Cross-reference this with your bank transactions. This is difficult for one purchase entry. Imagine if you lost 1000 purchases. Imagine if you lost 100 customers. How could you get them back?

Static Data

Table Countries with CountryId CountryName

This table grows much less rapidly. You could start out with all the countries in the world, using standard reference data. Or if you are a retailer, you may want to start out with your single starting country. Whatever the case, a change to the table results from a change in the business. You would expect this occurs at least an order of magnitude less often than adding customers.

If your dynamic data references static data, like customers have countries, then you will have to manage the foreign key link between them. This means static data cannot be replaced without thought to original references.

Look at change frequency