I’ve been caught up in a big project here in the workplace over the last couple of weeks, mainly revolving around registration for 13 or so different classes that launched last week. In addition to answering a multitude of general questions about the location of the classes, dates, times, childcare, books, cost of classes, and if coffee would be served, I also became keenly aware of the need for good data in a database. As I am responding to emails to help people register for classes, I encountered a large number of duplicate entries in the database. Although I am not writing any code on the back-end, I still found it valuable to realize some the database structural foundations as an end user.
End users of a database that are mainly doing data entry, say, entering names, phone numbers, or email addresses into the database to register people for a class, should be aware that a person could already exist in the database, but possibly have a misspelled name, a new address, or a different home phone number. I came across multiple merge situations over the last couple of weeks, sometimes finding 3 or 4 records for the same person. It takes a little detective work, but I think it’s worth it. I looked at email address, activity history, family relationships, cell phone numbers, addresses, and birthdays to find clues about whether two records were most likely the same person or were in fact, two different people. It probably won’t make a difference in performance for the database, but it’s nice to know that you have good, solid data, rather than 6 people named Joe Smith and not knowing which one is the real Joe Smith who wants to register for this class.