Sequential or Random Access snack machines
Of Databases:
As a Database Administrator (DBA) by profession and training, I understand a bit about database technology. I have learned about the early versions that required data to be read sequentially. If you had to use a phone book sequentially, that means in order to look up someone with the last name Smith, you would first have to scan past every other name in the book that came before Smith. Anderson, Barker, Cadwell, etc. For some purposes, this was acceptable, since machines were doing the work and it was much faster than a human could do the same thing.
The next major improvement became what is called a Relational Database. This allows the data to be retrieved from any place in the table without needing to read all the records before it. This makes a database more efficient and practical for data sets with very large numbers of records. This allowed what we consider random data access.
Of Snack Machines:
Snack machines allow for the buyer to choose which product (record) they want. Press A1 for m&m's, B4 for Milky Way, C3 for Trail Mix or D5 for Zingers, the choice is yours. When you make your choice, the machine (database) activates the spiral for your product, dropping it into the tray for your snacking pleasure. The selections can be made in any order without a difference in how long it will take to get your snack (data).
So databases and snack machines are both relational. HOWEVER, you may have seen vending machines that intentionally break this by putting different snacks in the same selection. So A1 may be plain m&m's now, but the next one might be peanut m&m's. This is very frustrating if you want peanut m&m's now. One option the vending machine people have is to use the choices as separate selections. This way, A1 will always be plain m&m's and A2 will always be peanut m&m's which is great for thos of us who will only eat plain (or peanut) m&m's. Unfortunately, space is at a premium and doing things like that means that other choices will no longer have a spot, so maybe the Milky Way or 3 Musketeer fans lose out.
In the same way, sometimes people will take a field in a database like SourceID and instead of using it for the ID of the referral source, will use whatever sounds right. Now SourceID has valid entries like TV101 (for a tv advertising campaign) or EC (for existing customer) along with invalid entries like Bob (the name of the friend that referred them) or TVINET (because they saw an ad on tv as well as an email). The problem with these invalid entries is that the people in charge of analyzing the success or failure of a marketing campaign no longer can accurately tell how much business impact a given campaign has produced.
As a Database Administrator (DBA) by profession and training, I understand a bit about database technology. I have learned about the early versions that required data to be read sequentially. If you had to use a phone book sequentially, that means in order to look up someone with the last name Smith, you would first have to scan past every other name in the book that came before Smith. Anderson, Barker, Cadwell, etc. For some purposes, this was acceptable, since machines were doing the work and it was much faster than a human could do the same thing.
The next major improvement became what is called a Relational Database. This allows the data to be retrieved from any place in the table without needing to read all the records before it. This makes a database more efficient and practical for data sets with very large numbers of records. This allowed what we consider random data access.
Of Snack Machines:
Snack machines allow for the buyer to choose which product (record) they want. Press A1 for m&m's, B4 for Milky Way, C3 for Trail Mix or D5 for Zingers, the choice is yours. When you make your choice, the machine (database) activates the spiral for your product, dropping it into the tray for your snacking pleasure. The selections can be made in any order without a difference in how long it will take to get your snack (data).
So databases and snack machines are both relational. HOWEVER, you may have seen vending machines that intentionally break this by putting different snacks in the same selection. So A1 may be plain m&m's now, but the next one might be peanut m&m's. This is very frustrating if you want peanut m&m's now. One option the vending machine people have is to use the choices as separate selections. This way, A1 will always be plain m&m's and A2 will always be peanut m&m's which is great for thos of us who will only eat plain (or peanut) m&m's. Unfortunately, space is at a premium and doing things like that means that other choices will no longer have a spot, so maybe the Milky Way or 3 Musketeer fans lose out.
In the same way, sometimes people will take a field in a database like SourceID and instead of using it for the ID of the referral source, will use whatever sounds right. Now SourceID has valid entries like TV101 (for a tv advertising campaign) or EC (for existing customer) along with invalid entries like Bob (the name of the friend that referred them) or TVINET (because they saw an ad on tv as well as an email). The problem with these invalid entries is that the people in charge of analyzing the success or failure of a marketing campaign no longer can accurately tell how much business impact a given campaign has produced.
Comments
I promise.