changelog shortlog graph tags branches changeset file revisions annotate raw help

Mercurial > org > blog / draft/a-lispy-database.org

revision 21: 1204cefcfd28
parent 20: 889759cafcc2
child 22: 8a6b4b2f68cb
     1.1--- a/draft/a-lispy-database.org	Thu Jun 06 23:15:38 2024 -0400
     1.2+++ b/draft/a-lispy-database.org	Sat Jun 08 00:21:48 2024 -0400
     1.3@@ -1,26 +1,33 @@
     1.4 #+title: A Lispy Database
     1.5 #+options: toc:t h:1
     1.6-#+setupfile: ../../../clean.theme
     1.7-One of the key features missing in the =core= is a DBMS. The first,
     1.8-and often only choice for this need in companies of today is
     1.9-a SQL RDBMS.
    1.10+#+setupfile: ../../clean.theme
    1.11+
    1.12+One of the key features missing in the Compiler Company [[https://vc.compiler.company/comp/core][core]] is a
    1.13+reliable [[https://en.wikipedia.org/wiki/Category:Database_management_systems][DBMS]]. It's something that I've worked towards in Rust, and
    1.14+now in Common Lisp, but haven't gotten to a production-ready state.
    1.15+* SQL
    1.16+The first, and often /only/ choice for this need in companies of
    1.17+today is a SQL RDBMS.
    1.18+
    1.19+The SQL ecosystem has client-server systems like PostgreSQL, and
    1.20+embedded offerings like SQLite. Whatever lang you use you can
    1.21+basically always count on there being SQL support for your DB needs.
    1.22 
    1.23-There are client-server systems like PostgreSQL and MySQL, and
    1.24-embedded offerings like SQLite. Whatever lang you use you can count on
    1.25-there being SQL support[fn:1]. To support all the different SQL
    1.26-flavors though, a new abstraction has been summoned - the ORM.
    1.27+You might ask yourself, why choose anything else? We all know friendly
    1.28+neighborhood SQL and understand it. Many of us have never used
    1.29+anything else because we /don't need to/. You can represent fairly
    1.30+complex relationships in the RDBMS model and have an ecosystem that
    1.31+supports it wherever you go.
    1.32 
    1.33+My answer is simply - just because SQL is good enough, doesn't mean
    1.34+it's always the best choice. It is designed for Table-oriented data
    1.35+and that is where it should remain according to the CC.
    1.36+* Prolog
    1.37+* Key-Value Stores
    1.38+** RocksDB
    1.39+** Blobs
    1.40+* Objects
    1.41+- [[https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapping][ORM]]
    1.42 The ORM maps the object system of your lang to SQL tables, columns and
    1.43 rows and provides an API for you to manipulate the database in a more
    1.44 idiomatic way.
    1.45-
    1.46-You might ask yourself, why choose anything else? For good reason. We
    1.47-all know friendly neighborhood SQL and understand it. Many of us have
    1.48-never used anything else because we don't /need/ to. You can represent
    1.49-fairly complex relationships in the RDBMS model and have an
    1.50-ecosystem that supports it wherever you go.
    1.51-
    1.52-My answer is that just because SQL is good enough, doesn't mean it's
    1.53-always the best choice.
    1.54-
    1.55-[fn:1]