Database Principles -- do they always apply?

During my yoga practice I try to keep an open mind. Being willing to throw out my traditional learning and try something new. Call it experimentation or being flexible or open minded. My database education began at Michigan State University (Go State!) and learning about relational database design (very traditional). Let's just say that there are very specific principles to follow (normalization, uniqueness, keys, domains, etc.). This is my traditional learning. Something engrained in my psyche. Seriously .. engrained! But, hang on, this isn't about database principles! I want to discuss the importance of these principles and understanding them for the nonprofit organizations that I've been teaching. Could it be that some of these principles don't make sense for the needs of some organizations? I tend to find myself wandering to the normalization portion of the principles because I find it much more challenging to explain to others. Just as with yoga, we tend to focus on the poses (exercise) although yoga's basic principles are much more. Maybe it's because the results are immediately. Anyway, it's only natural to gravitate to something.

That being said, please bear with my fixation on normalization and listen to this musing... maybe there are times when normalization just doesn't makes sense. What do you think? Could this be true?

Thinking about this further, I have found the Salesforce.com platform quite solidly built. A system built with all the database principles. Organizations build on top of this solid system. So, maybe the rules don't matter. That being said, what is the big deal if they end up with three fields that say something like: Child 1, Child 2 and Child 3? Do they really need to normalize by creating a separate related table to hold each child's name? I guess the question is, are they okay with recording only up to three children? What if they need more? Are we stuck? Actually, with Salesforce.com it's not a problem. We just create another field. Yes, it's really that simple.... I would ask more questions, but I do think my purist mindset has shifted! I still struggle with this shift. My mind wants to go back to normalizing since it's my nature. But, the shift has begun as I now question myself when I start to normalize.

Another principle I've seen in action is related to duplicated data (uniqueness). I've seen some individuals at organization completely freak out about duplicated data, and that is good. This principle has been fully embraced, but I have been wondering about this principle too. Maybe we need a shift here too.

For example, what if we already have a contact in the database with their work information but we also interact with this individual at their house? The reality is that we have two separate communications to them. We want to snail mail to their house AND work with different information (think board member vs donor). So... maybe it makes sense to put their information into the database (dare I say it) TWICE. So, we duplicate their data.... BUT, the data isn't really duplicated. This person is really TWO DIFFERENT PEOPLE (well, not really, they wear two different hats, but you get the picture). But, we want to know that they are the same person. How to do that? Well, Salesforce.com's Nonprofit Starter Pack offers something called Relationships. So, you can create relationships between two contacts. There, all better, right?! What do you think?

So, it's really not important to always normalize or de-dupe your data. It is important to understand the impact of your decision. In other words, how will I be able to report this information? Does this mean more updates of data? What do I need to do to import my data? Do I need to do anything special to my data to make this work?

Please note, I'm not suggesting we throw away our principles. Of course, we are building on top of a very well constructed database. One that is following the rules. I only suggest that while I try to blend my yoga and database education, maybe it makes sense to change the view a bit and rather than labeling something as a wrong, we just look at it again and see if it's truly bad or will it fit the users' requirements and make it easier for them to continue on their learning path.

So, with a yogi's open mind, I welcome all discussion on this topic of database design. I am very interested in hearing from everyone and anyone on this as my learning will expand with your input and viewpoints.

Want more support?

Ready to start a trek designed for your nonprofit? We can help!
We offer full-service treks, one-time support through our Outpost program, personalized training, and more. Get in touch with a Sherpa to talk about the bridges your nonprofit is building.