# What

The abstract of the SRFI is the following:

This library is a generic approach to the database abstractions known
as triple-store and quad-store. Generic Tuple Store Database implements
n-tuple ordered sets and associated primitives for working with them in
the context of data management.

So SRFI-168 is a generalisation of triplestore and quadstore. This is some

what similar to Entity-Attribute-Model, datomic and the databases that

implements the Resource Description Framework which includes SPARQL

query language. Such databases includes BlazeGraph, Virtuoso and Jena.

This library is not a datomic clone but it shares some similarities. Also it

doesn't try to be conformant to RDF standard in several ways.

Compared to datomic it is not versioned. Also nstore doesn't allow time travel

queries. It does not require datalog queries because a) I do not have a good

grasp of datalog b) what looks the more like datalog is minikanren but, at least

in my experience, it is not very efficient c) Requiring datalog or minikanren

would, in my opinion, require to much work from implementations and make it

more difficult to grasp.

Instead, nstore rely on `from` and `where` procedure that allows to express

complex queries without requiring complex macros. This is the building blocks

upon which higher level query language can be based, in particular minikanren

querying can be based on those (which could be part of the sample

implementation without making it a requirements of the SRFI).

nstore querying boils down to stream processing. Indeed, `from` procedure

must return a stream of bindings which can be transformed into other streams,

possibly refining the query with `where`.

# Why

The current rationale paragraph is:

The industry standard for durable data storage, namely the Relational Database Management System (RDBMS), does not blend nicely into Scheme. In particular, the SQL programming language is very difficult to embed in Scheme without fallback to string interpolations. This could explain the poor support of RDBMS in Scheme implementations.

This SRFI proposes a powerful database abstraction for storing and querying data that integrates well with the existing Scheme landscape by reusing SRFI 9, SRFI 128, SRFI 146, and SRFI 158, and relying on the Ordered Key Value Store SRFI. This SRFI comes with a memory storage engine that supports transactions. It can easily be adapted to implement durability relying on one of the various existing ordered key-value store libraries available in the wild.

This SRFI does not overlap with existing SRFIs.

I don't think it is the whole story:

I wanted to give an example SRFI that builds upon other SRFIs, to express that the SRFI process is useful to build higher level abstractions that are (to my mind) pratical, useful and that this effort is not in vain. I know that several SRFI rely on SRFI 128 and that SRFI 9 use is pervasive. Still, to my knowledge there is no other SRFI library, as of yet, that re-use as much existing SRFI.
I wanted a better story for scheme data durable on disk as a replacement for "use files to store your data (prolly serializing `write`)"

nstore is the result of several years of research to find a database abstraction that is general enough to be applicable in wide variety of contexts. Here are my requirements:

- Low learning curve. I am completely biased here. Even if SQL is part of most curriculum, I think it much more easy to approach database work on data structures that are well documented and also part of the curriculum namely red-black trees. Querying is also less magic than in SQL, it is just a manipulation of streams. The absence of fixed schema (also known as "schema-less") helps to dive into on-disk persitence. Garbage in. Garbage out. One could get some inspiration from datomic for a more strict approach.

- Allow to efficiently represent relational data. Most CRUD apps rely on some sort of graph structure, more commonly trees. Anyway, nstore provides the ability to store and query both efficiently.

- Support for ACID transactions across "documents". nstore support transactions and the sample memory based implementation too. It is also true that an implementation can forgo that part and provide fake transactions. This is the usual practice when working with RDBMS that indices are updated along the actual record. Transaction support allows to keep the data and its indices always synchronized.

Also, the nstore allows to implement efficiently n-dimensional indices (via Xz space filling curves) and full-text search. Unlike graph databases which must rely on external indices, the nstore allows to both index text and n-dimensional numeric data. Those will not be part of the nstore specification but will be added as example use of the nstore in the sample implementation.

Long story short, nstore library allows to achieve truly multi-model database that is both efficient and scalable.

One last word about the "generic" part of the specification. It was created as such because a) it possible and more elegant b) it is the basis on my work-in-progress immutable quad store.