Frequent readers know that topics often cluster together in my world. This month databases seem to be a recurring theme.
I love databases because I have lots of bits and pieces of information in my life. My databases take lots of different forms. I have some that are stacks of index cards secured by rubber bands. I have some temporary ones that are multiple colored stickies that can be rearranged on the walls in different sort orders. I have some that are in contact management applications. I have some in web-accessible mysql containers. And others live in FileMaker.
You'll notice that I have a pretty board definition of the term database. For me, a database is a collection of data managed by some sort of tool that lets me store, search, find, sort and otherwise manipulate the data in ways that turns it into useful information. The tool and its complexity is varied because the volume, type, and use of information is varied.
We've been using databases roughly forever. It's a core need, the ability to gather, store and manage information. It is a task that, quite frankly, can sometimes be a pain in the posterior if you know what I mean. There's a lot of little details involved and in the end the database - whether it is computerized or on paper index cards - is only as good as the facts it was fed.
Which is why it is only natural to look for a miracle!
But guess what? The miracle is a myth.
No matter what tools you deploy, no matter how clever the computer application, how suave the user interface, how intuitive the search form and results display, the old rule remains true. Garbage In, Garbage Out.
At its heart, databases are human editorial functions. Computerized tools might make us faster or let us search and sort in different ways, but they don't create the content. They don't maintain the content. And they can't verify that the content is accurate.
You can license the best software in the world, you can hire the best database programmers, can you can design the best system in the world - but you can't populate it without a human behind the wheel.
Now, I'm not for a second saying that the design of the technology doesn't matter, because it does. For example, a well-designed search interface that produces meaningful results is critical. And correctly defined fields and relationships bring forth the power of structure. But that's the second step.
The first, most important database decisions isn't "Oracle or mysql?" No, the first most important decisions is "Who owns this database?"
That is, who will enter the information - maybe through typing, maybe through an import procedure from a legacy system, maybe through scanning. The method matter less than the clear ownership of the task. And, who will update the information on a regular basis? Who will give it the care and feeding that data requires?
Please don't answer "the community." That's another huge database myth. Over and over both studies and real world experience show that most people use content. Far fewer create it. And database entries are content. Created by humans. Created by humans who 'own' the task.
Because we are seeking miracles, another common database myth is that more is better. More information. More technology. More complexity. Somehow, there's this idea that the more we can, in theory, do, the more powerful it will all be.
The reality is exactly the opposite. LESS is more. Simple is good. I've seen people spend thousands upon thousands of dollars on software for a small set of information. If you calculated the cost per record you'd blanch. For $25 and a trip to the local office supply store you could create a simple paper-based tool that would be way more effective and have a minimal learning curve. But that wouldn't be a miracle.
I confess that I've gotten hooked into this game. At one point in time I spent an embarrassing number of hours trying to program all sorts of features into a FileMaker database that held information about my albums (you know, those plastic discs that were left behind on the curb five or six moves ago ...) I took months creating ways to query information that I'd never before needed to look up, didn't really have a reason to look up, and in the end, never had the energy to fully enter into the database either.
Oh, that's right, there it is again. No matter how much fun you have programming them, databases are an editorial function that require someone to actually input real data. Manage it. Maintain it. And add human value to it. Then, and only then, does the tool begin it add its value too.
Become a Member
