From: John Cowan <xxxxxx@ccil.org>

Date: Thursday, September 19, 2019 3:34 PM

On Wed, Sep 18, 2019 at 3:10 PM <xxxxxx@ancell-ent.com> wrote:

I'm not sure myself, but I see the following advantages if it can be  pulled off without significantly increasing complexity for the user:

- Could provide a common interface for some fraction of non-SQL databases more sophisticated than KVMs that have similar interaction styles, that is, it would be a true DBI, vs. a RDBI.

I think that if what's returned from the database is not (broadly construed) a relation with a (normally fixed) number of columns and a variable number of rows, it's going to need a very different API, which of course will share some parts with this API.  For example, if you are returning a portion of a graph, the notion of a result-set makes no sense.  Of course, there are relations outside relational databases, like single sheets of spreadsheets and CSV files.

A wide column store is a type of NoSQL database. It uses tables, rows, and columns, but unlike a relational database, the names and format of the columns can vary from row to row in the same table. A wide column store can be interpreted as a two-dimensional key-value store.

CREATE KEYSPACE MyKeySpace
  WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 };

USE MyKeySpace;

CREATE COLUMNFAMILY MyColumns (id text, Last text, First text, PRIMARY KEY(id));

INSERT INTO MyColumns (id, Last, First) VALUES ('1', 'Doe', 'John');

SELECT * FROM MyColumns;

Which gives:

 id | Last | First
----+------+------
  1 | Doe  | John

(1 rows)