The Deconstructed DBA
In the beginning, there was the zero. And the electrical engineer saw that it was good. But the zero was lonely, so the electrical engineer created the one, to be the yang for the zero’s yin, the helpmeet and partner, to go where it went, to provide a substance and a purpose. And the electrical engineer saw that it was good.
But the zero and the one could not do anything by themselves. So the electrical engineer created other zeros and ones, and made the op codes and the registers to hold their transitory states, so the zeroes and ones could grow, and operate on each other. And the electrical engineer saw that it was good.
But the transitory states were still transitory. The zeroes and ones could not survive on their own. They needed a way to persist, or to at least remember their state so they could be recreated. So the electrical engineer created storage. And the electrical engineer saw that it was good.
But the storage was static. Once it was used, it could not be re-used. So once the state of the zeroes and ones was persisted, it became stagnant. So the electrical engineer created rewritable media, and the devices to write to it and read from it. And so the zeroes and the ones could be persisted, and they could be recreated, and they could be persisted again, and recreated again. And again. And again. And the electrical engineer saw that it was good.
But at some point, the electrical engineer realized that he could use the storage to make copies of the zeroes and ones on other, separate devices. And so the fork came into being. And the electrical engineer thought it was good, but he had introduced the Tree of Branches into the garden.
And the zeroes and ones proliferated. Each device had it’s own version, and other electrical engineers thought they could guide the zeroes and ones better, and so the groups of zeroes and ones diverged and were not the same.
And the electrical engineers gathered with stormy brows and belief each in his own righteousness. And they contended, and they deliberated, and they warred, but eventually they came to enough consensus to establish rules about the behavior electrical engineers should use to guide zeroes and ones. Thus the Standards Organization was born. And the electrical engineers saw that it was good.
And the devices with their sets of consistent zeroes and ones could coordinate, and they could be specialized to do portions of the work of all, and they could stay in harmonious synchronization. And the Standards Organization saw that it was good.
But some devices with their zeroes and ones had too much work to do. So the electrical engineers decided that some sets of zeroes and ones could be copied onto new devices to share the work. And because of the Standards Organizations, the copies were perfect, and the work could be accomodated. And they all saw that it was good.
But because the new devices were not stateless, each had its own set of persisted zeroes and ones. And because the work to be done on each device was persisted separately, soon there was a difference in storage, and the devices were separate and standalone.
So the electrical engineer decided to create a new device. It would hold the state information for every other device, and would share that information with any device that could connect to it, to protect it and to ensure it was available and secure. And thus the Database was born. And the electrical engineer saw that it was good.
But there were situations where two devices needed to operate on the same groups of structures at the same time. The work was divided, but the zeroes and ones on the new device were grouped so that they were vulnerable if two devices needed to change the group. And so concurrency was born.
But the electrical engineer was no longer an electrical engineer. He had passed from dealing only with ones and zeroes, with currents and gates and such. He was now dealing with entire groups of ones and zeroes that could be assigned structure and meaning. And those structures could be grouped, and retrieved, and passed to those devices that requested them. And it was good. And thus the electrical engineer became a programmer.
And the programmer was clever, and was able to create a new set of instructions for how to deal with precedence of work, and so the queue was born. And thus the Database Management System was born. And the programmer saw that it was good.
But there were many other issues to deal with besides precedence of work. There was also deciding which devices would be allowed to connect to the new device, how the new device could be set to rights if some of the work went awry, how to make sure groups of zeroes and ones could be speedily routed to their destinations, and so forth. And so the programmer created the row lock, and the security system, and the logs of transactions and of system, and the cache and the index. And the programmer saw that it was good.
But the programmer was weary of his creation. The programmer wanted to create something new, something fresh, something different. And so the programmer forgot his roots as an electrical engineer, and the angels quietly wept.
But there were some programmers who refused to abandon their origin, who remembered that those issues discovered during creation were STILL issues that had to be accommodated. So that groups of zeroes and ones could persist, and be correct, and consistent, and protected, and accessible, so that the work could be done. Thus the programmer became a Database Administrator. And the Database Administrator carried the message of sharing, and of concurrency, and of security and accessibility for all who had need.
And it was good.
