A relation is just a special kind of set construction and redis has sets, so relations can be built. All of logic and operations can be built from either (not + and) or (not + or). You have SISMEMBER (not), SUNION (and), and SINTER (or).

That might be enough.

Sorry, I didn't mention that redis has SADD and SREM for implementing projection. I'm not sure what you mean by select. You're right about product. I think that's what's missing.

Also, union corresponds to and and intersection corresponds to or

That's exactly what I said. We both got it backwards.

"Select" is the SPC-algebra operation which gives you the subset of a relation whose tuples satisfy some Boolean condition, e.g. firstname='bob'.

If you don't like it, I'll not tell the word "relational" since it is not very correct in this context, but this model is mathematically and algorithmically similar to what is inside the implementation of MySQL for instance.

To state it more clearly, in this model, the access pattern is not already implicit in the way data is stored by the user. With Redis lists it's pretty obvious (and you can see in the doc the time complexity of all the operations), that if you use LPUSH against a list, then with LRANGE you can get the top 10 items in constant time regardless of the length of the list: this is because of the data model, Redis lists are already ordered because they are just linked lists, and so on.

This is not to say Redis is better or MongoDB is better, it's just a different point of view, MongoDB implements a smart subset of the features provided by an RDBMS while Redis tries to take a different path where you select a data structure that is the best for the way you'll later retrieve those data.

Sure. I didn't mean to imply any criticism, or imply that you were criticizing. I, personally, haven't figured out when/where to use a document database like Mongo or Couch, but I figure they must be a good fit for someone's use case or people wouldn't be making them.

The thing that I have trouble with is that in every presentation or discussion I've seen of these alternative databases the people presenting them never seem to have an understanding of what a relational database is. And because the language in these presentations is always so obfuscated (to me) I'm never able to get a clear idea of what exactly they do and where they stand in relation to a relational DBMS (by which I mean the platonic ideal of a relational DBMS, not SQL).

Redis is interesting to me because it's unlike the others. And because of the way it's unlike the others. It has data structures with operations. In other words it's a DBMS, or "structure server" in your terminology.

At its core a relational DBMS is just a "structure server" with one kind of data structure, called a relation, and operations on that structure. And that's all it is really. Others probably disagree but I think even a query language is optional. The query language is just the UI.

SQL confuses everything. A SQL DBMS is a relational DBMS (almost) plus a boatload of additional functionality. I see your point about how Mongo is like SQL because it has named values and queries, but it doesn't have relations or relational operators.

In summary: Mongo may have some SQL like features, but they aren't relational features. The set features of Redis on the other hand are getting close to the building blocks of the core of an actual relational DBMS.

Btw in Wikipedia I read: "A short definition of an RDBMS may be a DBMS in which data is stored in the form of tables and the relationship among the data is also stored in the form of tables."

Basically once you have the idea of tables, a lot of things about SQL databases are automagically needed: queries and indexes for instance.

Also MongoDB supports _id fields specifically. And tables, so you can build tables that have as unique goal to describe relations among other tables. So MongoDB is an RDBMS following the definition of Wikipedia, that may be wrong of course (and if so should be fixed).

With Redis Sets probably it is possible to build the storage system of an RDBMS just with software on the client library side, but it can't be considered an RDBMS AFAIK because of the lack of tables, and Sets can't be considered tables since they don't have the field:value idea at all, but are just collection of elements.

Btw in the future I'll try to use the term RDBMS better, and will refer to Oracle, MySQL, Firebird, DB2, and so forth, as SQL databases.