When implementing a technology solution that involves a database, somewhere along the line you will have to decide on the fields required. That is, the information to be collected and how to structure it in the database. Sounds easy? Well, it is, in a way; these days, a databases can be whisked-up in two minutes, and frequently are.
The storage/processing power and software that makes this possible is amazing, but the skill of choosing the right fields is often underestimated. Often, lots of thought goes into what you would like to know, but very little to why you need to know it and crucially how you’re going to get it into the database.
Marketers are the worst offenders: they think about what they want to know, add the field to the list and then two years later it’s tumbleweed in there. Think about how many gaps there are in your core data and whatever is critical to you, then think about the difficulty you’re going to have populating other fields. Don’t get the wrong impression, data is good and you may want lots of it. But think ahead. Think about why you believe a field would be useful, test it’s value and then come up with a plan for capturing the information before building the fields.
Do empty fields matter? They certainly do. One day, a lot of time will be spent working out which fields matter, which should be removed and which cleaned up, before migrating to a new software or database solution. Do it well the first time and you will save money in migration and in on-going data maintenance, as well as making integrations a lot easier.
Remember, when specifying a field, the data will not just turn up. It will have to be coaxed, cajoled and wrestled into the database, so start planning how this will happen early in the game. Just because a field is built doesn’t mean the data will necessarily come.