Database interfaces

As part of cleaning up I stumbled across this draft that I apparently never published back in 2007. I'm a little more database savvy now, but I think the crux of the article still holds. Reprinted in it's entire, incomplete state due to my laziness to properly edit. 

Database interfaces continue to prove an enigma to me. I’ve tried to work with Access, MySql, along with a couple others whose names I don’t remember or have since blocked out of my mind. They’re wretched to setup, harder still to change, and seem to specialize in one of two categories:

Those that are easy to put information in.

Those that are easy to get information out.

Wikipedia is a great example of a database that’s easy to get information in. Bugzilla is another one. People who need to get information into a system love these types of systems. You freehand in information and do not require any particular type of structure. They’re very approachable, and great when you wish to amass information from a variety of sources very quickly.

But have you ever tried to compare two articles?

Let’s say you want to know the name of Franklin D Roosevelt’s dog. In wikipedia, you can probably find such a thing, but you can’t search for it directly. You have to search for Roosevelt, and then cull through the various pages that reference him to see if they mention his dog. You can add a string modifier to look for dog, which will reduce the time, but you still have to scan through the article to see if the information is relevant. Inconvenient, but not a show stopper.

But what if you wanted to compare articles referencing Roosevelt’s dog? What if you wanted to find out the context of someone’s life that an author would reference a famous man’s dog? There is no culling of data to gleam some greater insight. There is only an upchuck of that information that has already been deposited.

Now, on the opposite end of the spectrum, more business oriented databases like Access exist. My former employer used Access to keep track of clients, inventory, and various product models, as well as employee records. These systems require a lot of forethought. One must first consider Exactly what types of information you’re going to need to enter. For a product that you sell, you could include information like:

Sale price, sources of goods, prices your vendors charge, prices you sell for, etc. This is all well and good. Often someone who is entering information into the database needs a certain level of training so that they don’t enter numbers into a cell that requires text. However, you can design custom search strings to compare similar pieces of information. If you want to compare the prices of your different products, or look at what goods are the most expensive and the most cheap, you can do this fairly quickly and effortlessly.

But, if a year into the business you decide it’s time to start considering multiple vendors for a particular good you need, something you hadn’t thought of originally, your database needs a reworking to support all that. Cells have to be added, new information has to be entered. New queries have to be created, and some old ones have to be changed as they may not work anymore.