Pamela Grow recently asked me if I had a simple tool for establishing database protocols, which, being an utter database geek, of course I do.

I’m using the term “protocol” to mean “the proper way to do something” in other words, a system of rules.

And as far as I’m concerned, having everyone with permission to alter your database in any way on board with these protocols is as important as curtseying to the Queen.

Simply. Not. Negotiable.

The first and most important protocol is this:

Permission to alter the database (including adding names, changing addresses, etc.) is not a blanket right.

Anyone with permission to alter the database must be trained in protocols. Your temp help at high volume times should have only limited permissions, and their work should be constantly monitored (you wouldn’t believe the arguments I get into with the regular temps, who think they should get to set up the systems.) Your intern should not be the one to do database entry. For one thing, if the intern wanted to do something as soul-killing as database entry, he’d have a paying job. For another, you don’t want temporary staff, with no personal knowledge of your patrons, to be the one making decisions about data. If you’re lucky enough to have a general or development administrative assistant, that’s the person with this chief responsibility. If you’re a one-person shop, do it yourself.

Part 2 will include an adaptable tool, but in the meantime, here’s some good general rules:

Use as many drop-down and default entries as possible.
You want to minimize creativity in a database. As silly a mistake as typing “Mr” instead of “Mr.” can confuse the application. Never forget that computers are fast, and convenient, but frankly not quite as bright as your dog.

Put a value in every field
Blank fields are open to interpretation. Is “spouse” blank because there isn’t one, or because you don’t know the name? Use a simple value like “marriage status unknown” or “name unknown” or “Mary- deceased DATE.”

Databases are no place for politics
Most really up-to-date databases have finally figured out that spouses now sometimes have different last names. But a lot of small shops have old databases, with only one field for both names. So refer back to Emily Post, and use HIS name for the sort. Even really rudimentary databases will then have some field, either standard or user-defined that you can use for her name. (In fact, Emily Post and Miss Manners are extremely useful for all sorts of database pitfalls. They’ll tell you how to construct names for widows, divorced couples, adults in the same family with the same name, etc. And did you know you should NEVER separate a gentleman from his last name? “Mary and John MarriedCouple” not John and Mary MarriedCouple. I told you I like to geek out on this stuff.)

The reason for this is consistency. If you KNOW that you always enter a two-name couple using his name, you don’t have to remember which name to search. Also, if the entry is different from the protocol, then you know that this is due to a specific request from the donor. (But you should still make a note to that effect.)

Speaking of old databases
Older systems also will often default to the Last Name for individuals, but problematic for companies, where the individual contact may change. Either change the default entry to the company, or set up a placeholder record for the company that says “XYZ Corporation-see Smith, Mary”

And for goodness sake, USE your database
I know I said that your dog is smarter than your database, but frankly, your dog is also smarter than you. Don’t keep records in spreadsheets, which are dumber than all three of you combined. Use the report and query functions to maintain lists, not spreadsheets.

In part two, I’ll show you a simple tool for writing down your protocols.

Advertisement