text/html;charset=utf‐8 en Some thoughts on what databases are, what they do and why database,functionality,concurrency,serialization,recovery,acid,properties,interface,normalization,canonical index,follow global
‐what databases do and offer ‐a data access api ‐normally read/write, because they represent a universal set of access primitives ‐this is just one set of access primitives ‐e.g. in banking it would make sense to have an atomic move_money primitive ‐the precise methods offered affect recoverability, reorderability and the like ‐e.g. move_money primitives can sometimes be reordered when the corresponding reads and writes cannot ‐acid properties ‐atomicity ‐used to construct complex operations from a set of access primitives ‐concurrency ‐implemented in terms of serial, blocking calls to a given set of access primitives ‐essentially blocking/locking/transaction restart/etc push back into the control flow of the holistic, distributed application ‐isolation ‐serializability is a weak condition ‐e.g. if external races are present, whether an account transaction succeeds depends on the order of execution of the transfers ‐durability ‐logs are essentially about normalization of access patterns, history, undo information and the like ‐a standard data representation and interchange interface ‐policy enforcement and access control ‐the different functions of a database manager are usually combined, but do not have to be! ‐for example, if an external locking mechanism is present, competition over data never arises ‐sometimes it makes more sense to manage locks externally, at a granularity more suitable for the application ‐two‐phase locking is an example of a distributed implementation of atomicity in the presence of concurrency ‐as long as undo is possible, it doesn’t matter how it is implemented ‐so how about long‐running user interactions? they cannot be undone… ‐the acid paradigm only works as long as everything is contained inside the database; is this actually an artifact of centralization?