In 1977, Ben-Michael Schueler published a paper titled "Update Reconsidered" in "Architecture and Models in Data Base Management Systems", the proceedings of the IFIP Working Conference on Data Base Management.
Following the year 1347 B.C., when Amenophis IV died, a mass update of a large Egyptian Data Base was undertaken. Every record pertaining to Aton was erased with hammer and chisel throughout the country. We shall call updating of records on the ground that a truth valid up to a certain point in time becomes untrue, an Aton-Update.
In the year 47 B.C., the most important Data Base of that time, the library of Alexandria was updated by a fire, leaving most of the 700,000 book scrolls as a cinder. We shall call this kind of update an Alexandria-Update (whether through fire or other causes).
From ancient times through and culminating in the Middle Ages, books made of vellum and other recording media were reused by scraping of old writing - such as the Iliad or Euclid's Elements - and writing relevant texts. This kind of update is called a Palimpsest.
With the growth of commerce and trade, bookkeeping developed as an aid to tax collectors and revenue offices. It became customary to have a subroutine called whenever an update process was detected to chop off the right hand of the responsible merchant.
The invention of the manual card file provided an auxilary working tool for managing complex data structures. But the original record of events was kept in journals. New information related to a certain entity was appended to the bottom of the history of that entity on the respective card.
The introduction of punched cards changed the situation drastically. Updating a file was easily accomplished by reaplacing cards. Nobody seemed to care much.
The magnetic tape was the first and only Aton-Update-free recording medium.
Every update process causes necessarily a loss of information. The responsibility for this loss is usually delegated to the user and/or is counteracted by a highly redundant backup. The problem of recovery after a breakdown is attributable only to the updating process. Not because uncompletely processed transactions are lost in the system, but because the data base is inconsistent most of the time.
It seems plausible that a very large proportion of system expenses, limitations, and insecurities is directly or indirectly attributable to the update. The problems are scattered over the whole system, including the operating system, data management system, application programs, end user behavior, computer shop organization, etc.
It is clear that systems could be built at a fraction of the cost or with a multiple of the power if the update in the known traditional form could be eliminated. At the same time, reliability would increase proportionally. It seems that very few of our present problems would persist.
We have been told over and over again that we have to map a changing environment into our data systems and that quite naturally we must keep up the state description within our system with the changing world by our changing data. At the same time, we are aware of the fact that we cannot simply throw away past states because we have to rightly fear that circumstances will make them relevant again.
But there is a set of entities that never change: Events.
If we record all events from our Universe of interest, we can arrive by inference at the complete set of state-describing cross-sections up to and including the latest surface which in most circumstances will comprise the most relevant information.