11 Persistence: Key–value databases

This chapter covers

  • Designing a raw key–value database subsystem
  • How to introduce a type-safe interface to the key–value database subsystem
  • Designing a simple key–value database model
  • How to write generic, extensible code with advanced type-level features

Programs are rarely isolated, having no interaction with external data storage, such as a relational database, key–value database, filesystem, cloud storage, or something else. While the interaction model may vary, the idea behind it is always the same: being able to access a significant amount of data that can’t be located directly in the program’s memory.

In this chapter, we’ll use a new subsystem for the framework: the key–value database subsystem. It will be a low-level raw string-based (that is, unsafe) interface in the form of a new free monadic language (KVDBL). We’ll then proceed to the next step: enrolling a fully typed and type-safe interface on top of the string-based one (figure 11.1).

Figure 11.1 Framework subsystems: a new free monadic language is added to the hierarchy

I’ll demonstrate how to make the system more correct, robust, and convenient. We’ll also talk about extensibility, and on this journey, we’ll learn some useful type-level magic.

11.1 Raw untyped key–value database subsystem

11.1.1 Native key–value database libraries

11.1.2 String-based key–value database interface

11.2 Type-safe key–value database subsystem

11.2.1 Basic key–value database model

11.2.2 Approaching the type-level design

11.2.3 Type-safe key–value database model

11.2.4 Generic type-safe key–value interface

Summary