Relational Language

A data access and manipulation language conforming to the RelationalModel for database management (RelationalDatabase), as defined by EfCodd and refined by ChrisDate and HughDarwen.

-- LeandroDutra, et. al.

A distinction should perhaps be made of declarative language components and imperative ones. For example, Oracle's SQL-based language also has While loops and other imperative doo-dads borrowed roughly from the AdaLanguage. Generally the declarative side of the language is called the "query language". (Note - the WHILE LOOPs and AdaLanguage features exist in Oracle's PL/SQL rather than Oracle's implementation of SQL. A similar split exists in mySQL, postgres and SQLServer, which all offer procedural language extensions AND an SQL implementation).
It is sad to see SQL being the only widespread data language, as it really adds a lot of mess to the relatively clean conceptual model of relational algebra. The strength of the relational model is its enormously simple data model: in addition to data types (ints, strings, etc.), it only has relations, operators (projection, selection, join, union, sorting, and some others) and integrity constraints.

It would be great to be able to use, in production code, a language where one could say 't' instead of 'select * from t' and 't * t2 [foo = bar]' instead of 'select * from t join t2 on foo=bar'.

(The SQL standard has recently introduced a separate JOIN and WHERE clause - although not widely adopted by developers yet, I think this is a step it the right direction - one problem with current SQL syntax is that the WHERE clause is often a mess of assertions about the relationship between tables and set restriction. Of course, sometimes that is actually true).

Regarding "cell types" (int, string, etc.), Those are not really part of relational theory itself, other than the "types" being deterministic. The possibility of user-defined-types is possible, but I am a fan of dynamic typing or "type-free" anyhow. Regarding using "*" to mean "join", I am not sure I like the idea of symbols like that. It could get confused with multiplication, for one. It is not much shorter than join(t, t2 ,[foo=bar]). But I suppose specific syntax is a personal thing. I am just not ready for "relational Perl".

Of course, the "*" doesn't specifically mean join; 't * t2 [foo = bar]' would represent a multiplication, followed by a selection where the terms of foo and bar are equal... hence a join.

(Edit note: moved discussion to NullsAndRelationalModel)

I am working on a relational language for training and experimentation that has a BS12-like functional style, except that the arguments can only be one of 3 things:

  1. Tables - virtual or real
  2. Expressions that return scalars or tables
  3. Scalars (values like numbers or strings)

Things like lists of columns would be referenced as tables. There would be a short-cut syntax or functions (operators) to create things like column lists as tables. I have kicked around allowing tables of expressions, but am still iffy on that. The idea is that you know exactly what a parameter is, and it would be relatively easy to parse because you don't have funny parameter "types" like lists of column names. By making column lists be (treated like) tables, you can also do set operations to get column lists without hand typing each fricken column name if the asterisks (or their equivalent) don't do the job. A Schema() operation would return the schema of a given table as a table (DataDictionary) to be used for such purposes.

See TqlRoadmap

-- top

How about using Lisp to implement or define a relational language using EssExpressions? That would make it easy to parse and implement experimental or "lite" versions. However, it would doom it from PointyHairedBosses.

A relational Common Lisp exists in AP5. AP5 can be found at

And what about ConceptualQueries (ConQuerLanguage?) is it Relational? ObjectOriented? or it is in its own ConceptualLanguage? category?

See Also: SqlFlaws, EmbraceSql


CategoryLanguage CategoryQueryLanguage

EditText of this page (last edited May 12, 2014) or FindPage with title or text search