An Alternative to SQL?

Golygydd Max writes "Dave Voorhis from the University of Derbyshire has developed a program incorporating Tutorial D, a language designed to overcome of the shortcomings of SQL, and developed some years ago by Hugh Darwen and Chris Date. Until now, no-one had done anything with it but Voorhis is hoping for wider adoption; although we think it would be like pushing water uphill though." Update: 10/13 12:43 GMT by T : An anonymous reader writes "It's being picky I know, but the university in question is in fact called The University Of Derby, not Derbyshire."

Comments

Ever heard of TSQL?

[Sean80]

Ever heard of TSQL? Neither would have I, if I hadn't been forced to read about it in college. It would seem that there has been a huge number of variants of SQL over the years that have tried to make it "better." The benefits just never seem to outweigh the cost of learning a new language.

Re:What's the use?

[neurojab]

Have you ever seen a 25 way join or a 30 way UNION? I've seen queries that go past a given RDBMS's 32k query size limitation. Even worse, I've seen the code that GENERATES these horrendous queries. It's like seeing your parents having sex; it changes your life forever.

Please, please, there must be a sane way to query data from a highly normalized database.

Re:SQL is good for some things, but not for others

[glwtta]

I think you are confusing "SQL the language" with "MySQL the broken RDBMS implementation", both Postgres and Oracle can easily do what you want with hierarchies; as for user defined functions, support for those is implicit in most database systems (usually in a variety of languages, both SQL dialects and procedural).

I am not sure what's incosistent about the syntax you mentioned, but maybe that's just me. Though I'd be interested to see in what ways it is "very limited" (especially if those aren't the limitations of a particular databas engine, or relational databases in general).

Re:shortcomings to sql?

[Deorus]

Usually when you need to write queries for big databases, speed is a concern, so the lower the level, the better. I've never seen a GUI which could write SQL queries as well as I do.

Additionally, a high level interface is unable to undestand where a query can or cannot be optimized, but I can. For example: there are cases where queries have to be run on a regular schedule to update special optimization tables. These optimization tables are then used when user generated query (e.g.: from web input) comes, so that the user doesn't have to wait for the database to complete that subquery which could have ben run sooner. Only low level can give you such a control.

Small databases can well use high level interfaces, but those aren't the ones driving the standards anyway since the work is already easy for them. User-friendly interfaces such as Access, Query Builder, and crap like that already provide the required high level for the non-techies.

If anything comes to replace SQL, I think it won't stand standard long enough as vendors will start adding more and more odd extensions, so the story will probably repeat. Personally I don't care much about the language databases use as long as I feel in control and the general concepts of relational databases remain the same.

I think he's trying to say:

[Ayanami Rei]

I think he's trying to say that joins shouldn't be this hard to describe in the language.
Compare the symbolic forms:
Example, theta join
And the implementation in SQL:
SQL join example

Specifically in Tutorial D (and hence Rel) you would do this:

T1 = JOIN(EMP, DEPT)

And subsequently do shit with T1. That's it.

Re:shortcomings to sql?

[TheMiller]

It would be perfectly possible in a relationally complete language that includes a relational MINUS operator, without NULLs entering into it at all. And Tutorial D, on which the object of this article is based, does of course include such an operator. Whether NULLs are desirable or not is a matter of ongoing raging debate. I've found them easy to avoid, and queries of all sorts easy to understand without them.

Re:Any query language is going to be ugly...

[Tablizer]

SQL or any derivative thereof will be inherently complex. This is because SQL is merely an implementation of Relational Algebra. That's the key. Real RDBMS's are inherently mathematical in nature.

I disagree with the "ugly" premise. I have been working on an SQL replacement language myself (described briefly in another thread). I don't believe that (practical) relational operations are inheritantly complex or confusing. There are two problems with the way SQL and/or relational is often presented that gives the false impression that relational operations are inherantly messy, unnatural, and/or confusing.

First, the "base" operations that Dr. Codd presented with his relational papers are not necessarily the same operations that a relational language needs to present to the user (programmer). For example, in Boolean algebra, the "purist" (and only) operation is NAND (NOT-AND). Any of the other operations can be built with NAND alone. However, humans generally don't relate to NAND because our language has gotten us too familiar with AND, OR, and NOT. We thus use the human-friendly operations instead of the "purist" operations. The trick is to find relational operations that are friendly to humans, yet are still based on the "base" operations. As long as they are defined via the base (proper) relational operations, they are valid.

Second, SQL does not make it very easy to break big problems into smaller problems. The approach I envision would allow this. There would be intermediate virtual tables that would feed to later operations. One can concentrate on creating one virtual table at a time.

x1 = foo(....)
x2 = glab(....)
result = join(x1, x2, ....)

One can refer to chunks via name, whereas SQL forces one to nest stuff to acheive the same thing. (Plus, SQL sometimes requires one to duplicate something if two different "roots" of the parse tree need the same construct. By-reference instead of by-nest would fix the duplication.)