So I'm sitting on the plane and thinking that it would be a good idea to have a series of articles on some fundamentals. What fundamentals? You might think that I would bust out with some coolness on how to work with algorithms or something like that, but no. I have a better idea!
What about a series of articles on the crap that gets missed by most programmers. You know what I mean. Things like how networks work or how (and why) databases do what they do. I find it shocking that there are so many programmers out there today that don't know these basic parts.
I know that some you will read this and think I'm on crack. I mean after all why should we learn the intricacies of how these things work. What do we care? Seriously. Does it really matter? I think it does.
To get things started, I thought we would begin with a trip (not sure why but the Crystal Method just popped into my head) into the world that is the DBA's domain. It's interesting that even words like "domain" are so abused that we can't often understand how to speak with those not of our profession.
If we really want to go waaaaaaaaaay back, we would find that databases, or at least the concept of them, have been around for millennia. In fact, the earliest known "database" (that I am aware of, at least) was a bone found in some far off cave that was (presumably) used to track how many kills the cavemen (cavepeople? what is the p.c. word these days?) had made. Just to clarify, these weren't early serial killers they were tracking animals that they had killed. No one is sure why but I am pretty sure that the one with the most kills probably got a free copy of Vista :)
Many ancient cultures are known to have tracked their property using a variety of methods. Stores of grain, for example, had to be accounted for and, yes, they even had taxes back then. Except back then when you didn't pay your taxes you got much more than just a fine ;)
If you were to look at how we tracked data, you would find that we went from bones to clay tablets to paper (with a few incremental steps in between). Interestingly, once we got to paper we really didn't evolve much. We used paper for thousands of years with very little change at all for data storage.
Then along came computers. They would revolutionize data storage, right? Well, not exactly. When computers first came along all that we did was take the information on paper forms and put it all in computers. The only problem was we didn't eliminate the main problem with storing data on paper: duplication of data.
We had all this data for, say, a customer (name, address, phone, etc...) and then we had data for an order (customer name, address, phone, order number, etc...)--clearly there was duplication of data. In fact, this duplication had plagued us for quite some time!
The answer came in the form of a genius: Dr. E. F. Codd. He came up with a theory for data storage the eliminated the duplication issue (among other things) by creating relationships between the data. His ideas were rooted in an area of mathematics that deals with sets of information and used this in his application of the "Relational Database Theory".
What I want to do over with this series is to introduce you to the wonder and glory of relational databases. I know many of you know "how" to get data from a database but do you know "why"? I want to go back over the fundamentals to introduce some things that may have gotten lost in the shuffle. By doing this I think we can gain a better understanding of "why" we are doing the things we do.