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.

The StructuredQueryLanguage -- It did succeed in the market, but allegedly violates most principles of the RelationalModel.
- HibernateQueryLanguage - Variant on SQL with some OOP-geared extensions
Berkeley Ingres' QUEL
IBM BS12 (BusinessSystemTwelve)
Codd's Alpha
ChrisDate and HughDarwen's TutorialDee
AlphoraDataphor's D4 (based on TutorialDee?)
LEAP (perhaps)
Datalog is a language similar to the PrologLanguage that could be considered relational in some ways.
TqlRoadmap (TQL)

-- 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'.

In practice since very few would use a multiplication without a filter, I believe they should be combined into a single operator (join). (We can still keep multiplication.) Further, a functional style would be nice so that DBA's could more easily define their own operators without having to add new syntax. A new function that uses two existing functions is not new syntax, just a new function.

(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.

I am very new to DB work, having most of my experience in C++. Must the relational language paradigm be its own language? Or could it be implemented in a more conventional language with versatile syntax? C++ is restrictive in many ways, but operator overriding isn't one of them. Given templates and fun with operators, could a dandy relational-logic-system be created for C++? If not C++, perhaps Python? -- MartinZarate
Sure, see e.g. NotesOnaCeePlusPlusRdbmsApi. -- DanMuller
DoesRelationalRequireTypes

(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:

Tables - virtual or real
Expressions that return scalars or tables
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 http://www.ap5.com.

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