While this Glowdust obviously implements a query language very different from SQL, whichever differences exist between it and relational databases are not becau

While this Glowdust obviously implements a query language very different from SQL, whichever differences exist between it and relational databases are not because, as it claims, "It uses functions as a model for storing data". The so-called relational model and relational databases do not have an appropriate name, a much more suitable name would be relational-functional model and relational-functional databases. Even if, according to the usual definitions, the functions are a subset of the relations, for designing and using efficiently databases it is important to be very aware about the differences between functions and non-functional relations a.k.a. many-to-many relations. Any data table from a database is composed of 2 sub-tables, one that consists of relational columns, i.e. the so-called primary key columns, an another, which may be empty and which consists of functional columns, i.e. where each column is a function of the primary key. There are many relational databases that do not contain any relation, because all the tables have primary keys that consist of a single column. Such databases contain only functions. Only the tables where the primary key includes multiple columns contain relations. The most frequently encountered joins are not true relational joins (which create a new relation, i.e. a table where the primary key is the concatenation of the primary keys of the joined tables), but they just extend a table with functional columns that correspond to functions defined in tabular form instead of being defined by formulae. The true relational joins are those that match columns that are not the primary keys in any of the joined tables. The most frequently used joins match a foreign key in one table with a primary key in another table and such joins are just tabular function computations, they do not produce any new relation. So Glowdust might be implemented in an unusual way for a database management system, but if it is restricted to functions that does not make its use different from the many databases implemented with a relational DBMS, but which nonetheless do not actually use relations. Any relation can be modeled by a function, i.e. by a predicate defined on the Cartesian product, but this may result in less efficient implementations than when using a true relational DBMS.