A simple database

The simplest database in the world consists of:

  • an insertion method (db_set)
    • db_set 123456 '{"name":"London","attractions":["Big Ben","London Eye"]}'
  • a retrieval method (db_get)
    • db_get 42
  • a text file, as a log (meaning append-only) of key-value pairs

The write speed of this database is very fast because data is simply appended, but the read speed is very slow, at 0(n)

If we wanted to speed this up, we could use an index

many databases internally use a log, which is an append-only data file.

Foward and Backward Compatability Requirements of Databases

in an environment where the application is changing, it is likely that some processes accessing the database will be running newer code and some will be running older code—for example because a new version is cur‐ rently being deployed in a rolling upgrade, so some instances have been updated while others haven’t yet.

  • This means that a value in the database may be written by a newer version of the code, and subsequently read by an older version of the code that is still running. Thus, forward compatibility is also often required for databases.

The living nature of a database

When you are designing a database with relations, you have to consider that the database is a living object. At any moment in time, you have definitions and purposes of each specific model. However, as the needs of the database change and grow with your business, you need to be flexible to change the definition of models that no longer makes sense, given that business logic

  • For instance, we previously had the concept of a payment profile in the database, which was basically a credit card. Therefore, you might find a payment profile as "a way to pay". However, within corporations have coupons into the payment system, it became apparent that a coupon was really not to do similar from a credit card in the way that it would function. Therefore, it made sense to change the way that we thought of a payment profile. Incorporating coupons into this model meant reconsidering the name. Instead of payment profile, they would be called payment methods. Now the definition became something more like "some type of exchange good that you can pay with to receive a good in return". By allowing this definition to change, we were able to leverage existing functionality to incorporate new and unexpected designs into the database model.

  1. ACID
  2. DB Cluster
  3. DBMS (Database Management System)
  4. Local Storage
  6. Race Conditions
  7. Strategies
  8. Testing