diff -r 889759cafcc2 -r 1204cefcfd28 draft/a-lispy-database.org
--- a/draft/a-lispy-database.org	Thu Jun 06 23:15:38 2024 -0400
+++ b/draft/a-lispy-database.org	Sat Jun 08 00:21:48 2024 -0400
@@ -1,26 +1,33 @@
 #+title: A Lispy Database
 #+options: toc:t h:1
-#+setupfile: ../../../clean.theme
-One of the key features missing in the =core= is a DBMS. The first,
-and often only choice for this need in companies of today is
-a SQL RDBMS.
+#+setupfile: ../../clean.theme
+
+One of the key features missing in the Compiler Company [[https://vc.compiler.company/comp/core][core]] is a
+reliable [[https://en.wikipedia.org/wiki/Category:Database_management_systems][DBMS]]. It's something that I've worked towards in Rust, and
+now in Common Lisp, but haven't gotten to a production-ready state.
+* SQL
+The first, and often /only/ choice for this need in companies of
+today is a SQL RDBMS.
+
+The SQL ecosystem has client-server systems like PostgreSQL, and
+embedded offerings like SQLite. Whatever lang you use you can
+basically always count on there being SQL support for your DB needs.
 
-There are client-server systems like PostgreSQL and MySQL, and
-embedded offerings like SQLite. Whatever lang you use you can count on
-there being SQL support[fn:1]. To support all the different SQL
-flavors though, a new abstraction has been summoned - the ORM.
+You might ask yourself, why choose anything else? We all know friendly
+neighborhood SQL and understand it. Many of us have never used
+anything else because we /don't need to/. You can represent fairly
+complex relationships in the RDBMS model and have an ecosystem that
+supports it wherever you go.
 
+My answer is simply - just because SQL is good enough, doesn't mean
+it's always the best choice. It is designed for Table-oriented data
+and that is where it should remain according to the CC.
+* Prolog
+* Key-Value Stores
+** RocksDB
+** Blobs
+* Objects
+- [[https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapping][ORM]]
 The ORM maps the object system of your lang to SQL tables, columns and
 rows and provides an API for you to manipulate the database in a more
 idiomatic way.
-
-You might ask yourself, why choose anything else? For good reason. We
-all know friendly neighborhood SQL and understand it. Many of us have
-never used anything else because we don't /need/ to. You can represent
-fairly complex relationships in the RDBMS model and have an
-ecosystem that supports it wherever you go.
-
-My answer is that just because SQL is good enough, doesn't mean it's
-always the best choice.
-
-[fn:1]