I am constantly thinking of ways to store information in my databases and I need to be reminded time and again to not over-engineer my solution. Data needs to be simple to implement and maintain, as well as to report on.
I see organisations struggling with being able to extract information out of their database after spending so much time putting it in there. It’s a common challenge: each time something is added to the database, there is no consideration for what was done in the past to store this information and whether it is actually the right way to do it. Keeping things simple should make your queries and reports much easier to use as your data is always housed in the same places.
Keep it consolidated
Everything should have a proper home in your database. Think about what has been done before when it comes to adding new information. For example, perhaps your database has previously tracked a constituent’s interest in activism using a custom field called ‘activism’. Later on, you decide to track other interests, such as ‘conservation’ and ‘animal welfare’. Instead of creating two more fields, you could repurpose the original field, by renaming it ‘interests’ and then adding the values of, ‘activism’, ‘conservation’, ‘and ‘animal welfare’ to the field table. This keeps similar information together, which is beneficial for finding the information again.
Put it in the right place
It is also important to know where your data should go. If you have information that’s only related to the individual, and is not related to your donations, your actions/interactions or your events, then it should live on the constituent record. If the piece of information is event/activity based, then the information belongs with the activity of the event in question. Perhaps you have collected survey data. If the survey relates to a specific event or gift, it should always be stored against the event or gift record to which it applies. Otherwise it should be stored on an action or interaction record. If appropriate, certain responses can be stored as fields on the constituent record, such as biographical information, but in general survey participation and responses should be stored as an action/interaction.
Keep it clear and concise
Add the information you need, and nothing you don’t. The information you do store on your database should be something that you intend to use again in the future.
Let the data speak for itself
I have seen databases that have had extra fields added to flag information that already exists in the database. If you are tempted to do this, consider whether it is truly helpful. A challenge with creating values like “high value donor” or “active member” is that you need to constantly check these fields against other values and update these flags on a regular basis. There may be smarter ways to identify these records without you needing to create another field, such as using reports and queries.
Consider reviewing the information you currently have on your database, and find opportunities to consolidate and refine what you already have. This will get you on your way to a simpler and more effective database quickly!