The Problem with Databases

One of the greatest challenges for any animal shelter is selecting the mode by which you will maintain your data.  Before you start, you need to recognize that there is no perfect mechanism to record and maintain your data; when you finally make your decision, you’ll discover that it is all about compromise.

The first decision is that whether your records will be paper based or computer based.  Obviously a paper based system is the simplest method of recordkeeping, but it is a horrible system to query.  It is also doesn’t stand up well to the elements.  However, a computer based system is only as effective as the backup systems in place.  For example, I worked with a Houston shelter to recover their database files.  Their shelter staff faithfully backed up their data every evening onto a tape backup system without thinking that they should replace the backup tapes from time to time.  After years of using the same backup tapes, over the years they were backing up their data onto worn out (worthless) tapes.

Since a paper based system requires no explanation, I’ll jump into computer based systems.  The simplest computer systems use a flat file system; eventually an electronic paper based system.  Think of it as a paper based system on a computer.   Like a paper based system, it is easy to use and it allows you simple queries.   A flat file system is the easiest system to train your staff on, but it isn’t much help for driving statistics.  It is a good system for very small shelters or rescue organizations.

Anyone who has been in animal shelter for any length of time, you know that animal records are all about relationships.  A relational file system is the most common system used in maintaining animal shelter records.  But, those relationships can be confusing and so far there is no database system that you can purchase that can capture all of those relationships.

But, before you can decide on which relationships are necessary for your shelter, you need to decide if you want your data to focus on the animal or the incident (or event).  What will be the chief cornerstone of your data gathering?  Do you want to make the animal or the incident the center of your data gather.  In every occurrence, both will play a role.

The most common example is an animal intake.  The intake or impoundment is the incident and the animal is the other half of that equation.  Since most shelters wish to maintain monthly statistics, incidents (or events) become the cornerstone of their data gathering.  From that cornerstone event, other relationships begin to unfold.  And this begins the journey as to the complexity of a database program.  It is also the place where your eyes begin to glass over.

Usually a database is broken into data areas: animal, people and events.  In each incident, relationships paint the picture of what has occurred.  As with the intake incident described above: the animal has a relationship to the incident as “impounded.”  When the owner is found, the animal has the relationship as “owned.”  If an owner does not claim the animal, then the animal hopefully gains the relationship of “adopted.”  As so on…

To make the data easier to use, most software engineers eliminate obvious relationship to prevent the use from becoming overly frustrated.  For example:  Most database programs fail to recognize the association of household units.  People and animals belong to a household and households have relationships to addresses.  Failing to recognize those relationships, various household members could bail out their pet from the shelter without the shelter personnel realizing that the animal had been impounded multiple times.  It is a problem that exists when  shelter personnel allow their computers to do all of the thinking.

No animal shelter management software tool is perfect, in fact to make this tool work for you, you’ll have to create numerous workarounds to meet your needs.  When test driving an animal shelter software tool, look for data fields that seem to serve no purpose; those are the fields that you can later use when you need a workaround.