Slashdot Mirror
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."
Who remembers "Knowledgeman", that database language of 20 years ago which got eclipsed by dBase???
What are the shortcomings to sql? it seems to be able to handle anything you'd need it to do.
Try using Lotus Domino for a week. You'll be begging to go back to SQL.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
Is there anything that SQL can't do? I've been using various RDBMS for years and it hasn't come up yet.
I use SQL a lot and I agree that has failings. The clumsiness inherent in, say, nested joins is quite amazing when you consider how important databases are in modern industry. This is a consequence of the "near-English"ness that SQL strives for, but that property is also what causes people to adopt SQL in the first place. We'll probably look back at SQL in five years and laugh... but weren't people saying that five years ago?
apterous.org
so to overcome the (not really all that many) shortcomings of sql we will all learn how to use something completely new. Yeah, adoption going to be quik and complete........
"goodbye and hello, as always" ~Prince Corwin, from Zelazny's Amber series
The name doesn't help... "Tutorial D" doesn't sound advanced at all...
Try proposing to your boss to replace your mySQL database with "Tutorial D" for... no good reasons? Will happen. Soon. Right?
Eureka Science News - automatically updated
"SQL is sloppy and unpredictable; Tutorial D is a correct relational database language."
sounds a lot like
"C is sloppy and unpredictable; Pascal is a correct programming language."
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
Seems like it can handle just about everything but maybe I'm not thinking outside the box. The biggest limitation is my lack of knowledge about how to do the things I want to do.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
My buggywhip manufacturing plant uses good old fashioned chained flat files. No one in their right mind would EVER use some *toy* database structure, especially that whole relational database poppycock. balderdash!
meh
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.
For those of you that haven't been assimliated into the borg, microsoft's new version of SQL server accomodates for a new query language called XQuery which takes a lot of the best parts of XPath and XSLT and combines them and obviously the underlying framework is XML. This will cover a lot of the shortcomings over Transact SQL for those that are willing to adopt it, and honestly, it's really not that bad.
If you read the article, this isn't about replacing SQL, but more about testing new ideas and languages that could replace SQL. This is better than just saying, "We have a better language. Switch now or be assimilated.", and I'm glad someone's finally taking this approach. Unfortunately, the article only mentions one specific problem with SQL, but I'm sure there are others that these people might eventually solve.
Hurricane Ivan: A 17th century prison collapsed. All of the inmates escaped.
UPDATE tblUsers SET Karma=Karma-1 WHERE UID=743982;
liqbase
that SQL is SOL.
I have gas, but my car uses petrol.
Almost all the Object Oriented stuff people layer on predicates are, at best, an ad hoc, and poor, means of optimizing execution speed.
Let me explain.
One of the principles of polymorphism is that the same method has the same abstract meaning regardless of the kind of object. A predicate considered as a method subsumes such polymorphism by simply trying the various possible implementations of the method and committing to only those that succeed. If more than one succeeds then so be it -- that's the whole idea of relations as opposed to functions.
So, one reason you want all this OO stuff is the inheritance hierarchies keep you from going through all possible interpretations of a given method when the vast majority of them will fail for a given object.
Another, related, problem is that inheritance provides defaults without requiring a lot of thinking on the part of the computer. What I mean by "thinking" here is the sort of thing that is done by statistical imputation of missing data via algorithms like expectation maximization (EM) or multi-relational data mining via inductive logic programming.
So, the other reason you want all this OO stuff is so you can avoid mining a background database to provide reasonable defaults for various aspects of the data.
Some might be concerned that over-riding isn't absolute in such a system -- that you don't absolutely block, say, more generic methods when you have more specific ones present, and they're right. You don't block those methods -- you lower their priority by lowering the probability of those implementations via the statistical methods of imputation and/or induction. In a microthreading environment they most likely won't get any resources allocated to them before other higher priority implementations have succeeded. In a single threaded/depth-first environment they will be down the list of desired alternatives -- but they won't be discarded until something equivalent to a prolog cut operation kills them off.
However, and this is the important point, the work that has been expended toward OO facilities has vastly outstripped the effort that which has been put toward more parsimonious ways of optimizing predicate systems.
One of the better predicate calculus systems out there -- more promising due to its use of tabling to avoid infinite regress on head-recursive definitions and its optimization of queries using some fairly general theorems of predicate calculus -- is XSB. It has an interface to odbc and a direct interface to Oracle, but it would be better if it had something like a recoverable virtual memory substrate to support its roll-back semantics.
Seastead this.
Is right here.
From the introduction: "Rel is intended to serve multiple purposes:
-It is a tool for learning, teaching, and exploring relational database concepts in general;
-It is a tool for discovering the power and expressiveness of a true relational language;
-It is a tool for learning Tutorial D;
-It is a relational database server;
-It may serve as a prototype or "working blueprint" for future implementations of Tutorial D or any "D" language (more on this later);
-It may serve as a platform for experimenting with and/or examining database engine internals. "
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).
sic transit gloria mundi
For those interested, the paper describing this language (linked to from the article) is available here. There's a link to the grammar of the language at the end of that paper.
I use SQL quite a lot. It's certainly great for a lot of things, but it does have some limitations here and there. For instance, trying to deal with things like hierarchical structures, or joining on having identical/similar children, is a nightmare in SQL. Even if the query doesn't need to be efficient to run, it can still be extremely complicated to write and test. SQL simply wasn't designed or intended to deal with those sorts of structures.
Unfortunately, short of using external code outside the database, it's so often a choice between using SQL or nothing else for writing a query in a particular database rather than an option between SQL and another language. In some ways it's like being forced to write every program in C or every program in Java or every program in Lisp, where realistically one or another might be better suited to a particular task.
I suppose one of the reasons for only supporting SQL is that a predictible query language makes it easier to arrange data structures so they can be queried most efficiently. Still, it'd be nice to see an alternative front-end language or two supported in one or more of the major databases. Not every query needs to be ultra-efficient, and there have been many times where I would've liked to trade an efficient query execution for a language where what I wanted was more writeable.
Comment removed based on user account deletion
this proposed language is like a superset of sql. It also sort mixes itself with PL/SQL-like constructs as well. I think it's rather novel and it could make your optimization tasks easier if you had access to something like this... less trying to think in terms of the language, more in terms of how you want to acutally manipulate the data.
This is _not_ a query builder. It's going back, looking at what relational algebra is, seeing what people do with SQL, and then making sure the language has all the idioms required to be "complete" and not arbitrary.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
The article criticises SQL but the author has little familiarity with SQL for example:
"but the syntax is often inconsistent and unless you use one of the many vendor-specific supersets of SQL it can be tricky to express complex series of operations in a concise manner."
But in fact, SQL is so popular because complex expressions need little changing from specific vendor offerings. If people choose to program using the subsets, then well and good, but the ANSI standard is generally thought to be sufficient. This is like arguing for the abolishment of HTML and XHTML because Microsoft make a flawed browser - hopefully the database language is better than the reasoning here.
It then goes on to say "The idea is that there should be no arbitrary restrictions on the syntax of the query language, but at a lower level the database shouldn't run up against idiotic limitations. The limitation in existing implementations that generates the most comment from the various parties in the debate is the problem with "null" values in relational databases. Put simply, a database field has a type (50 characters, for instance, or a floating point number to two decimal places, or an 8-bit integer), but when you don't fill the field in (i.e. it's "null") it loses all its meaning. Even the ANSI standards state that if a field is null it's said not to exist - so if you ask a database for "all entries where field X is not equal to 47" it won't return any of those where field X is null because instead of saying "Null doesn't equal 47", the value "null" is deemed not to be comparable with any non-null field."
Well, for starters, null is not numeric zero, null is the absence of any data whatsoever, and every SQL doc in the world tells you to not mistake it for zero. Any arithmetic expression containing a null always evaluates to null. For example, null added to 7 is null. All operators (except concatenation) return null when given a null operand. That's exactly why it's the ANSI standard.
If you want to find "all entries where field X is not equal to 47" then pass your attribute a value like "0".
SQL is neither clunky nor obsolete. Tutorial D may actually be a better database modelling method, but the article's criticisms aren't sufficient to exault Tutorial D whatsoever. The "Project D" syntax and model may possibly be better, but these criticisms aren't a convincing reason to scrap SQL.
Si tacuisses philosophus mansisses. If you had kept quiet, you would have remained a philosopher.
select client.name, client.id, product.id, product.name, product.price from client_table client, product_table product where client.id = product.client_id and client.id = ? and product.discontinued = 0 order by product.price
Assuming you substitute something for ?, that will effectively join the two tables into one, and give you a list for all products from a certain client (given by ID) which have not been discontinued, and order these results by price.
The World Wide Web is dying. Soon, we shall have only the Internet.
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:And subsequently do shit with T1. That's it.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Jack Black and some bald dude have gotten into databases?
SQL was a language designed to allow relatively unskilled operators to be quickly trained for data entry using the language directly, and thus it was designed to be English-like, flexible, and forgiving.
SQL is only vaguely reminiscent of the true mathematics behind the relational data model. It continues to be used and expanded, despite its restrictions and shortcomings, because it is far and away more popular than any other database language.
The fundamental assumption of the relational model is that all data is represented as mathematical relations, or rather, a subset of the Cartesian product of n sets. Unlike SQL, in the mathematical model reasoning about such data is done in two-valued predicate logic (that is, without a null value), meaning there are two possible evaluations for each proposition: either true or false. The data is operated upon by means of a relational calculus and algebra.
The relational data model permits the designer to create a consistent logical model of the information to be stored. This logical model can be refined through a process of database normalization. A database built on the pure relational model would be entirely normalized. The access plans and other implementation and operation details are handled by the DBMS engine, and should not be reflected in the logical model. This contrasts with common practice for SQL DBMSs in which performance tuning often requires changes to the logical model.
I have been working on an SQL alternative myself for a while. My approach is more functional (not procedural) in nature. If the language is designed based on this, then new operations can be added without having to add to the syntax of the language. This would help vendor compatibility because if vendor B does not offfer an operation that vendor A does, then a DBA can simply add a clone of the "function" without tweaking the language parser.
Tutorial D uses infix notation, which tends hard-wire operations to a syntax parser. Prefix (functional-style) is more flexible, consistent, and easier to parse. For example, new parameters can be added to prefix without changing existing calls. It is just an extra, perhaps optional, parameter. It is hard to do with with infix.
My relational replacement would also make it syntactically easier to perform relational operations on things such as column name lists. The column list is simply a table in its own right (perhaps with syntactical shortcuts); thus it can have table operations (relational algebra) done on it just like tables. It is "conceptual reuse" you can say.
Table-ized A.I.
Quote
Most people who use databases in anger are familiar with the concept of a relational database.
Unquote
Maybe someone could enlighten me as to why the word
anger is in the first sentence of the article. Why
would using databases in anger be relevant? I use
databases in finanical situations, is that similar
to anger?
How is SQL "not good enough"?
Look, I don't mean to be terse, really, but a Slashdot post is not the appropriate place to give a freshman tutorial on database theory, and the very fact that you ask your question means you need one.
In that light about all I can say is that SQL corrupts data, gives the logically wrong answers to querys and ties the logical model to the physical platform (think of Java and the JVM for an idea of why this might not be a good thing for a cross platform data manipulation system).
If this answer does not satisfy the solution is simple, read Chris Date's introductory book. He's already written it. I'm not going to duplicate it here. Until you do so you will probably remain ignorant of what a database even is, which, per above, makes it rather hard to explain what's wrong with a particular implimentation (just as it would be hard for me to explain a problem in orbital mechanics to you if you hadn't at least gone through an introductory physics text).
Of course, you can always go to Fabian Pascal's website ( which Date is a contributor to), but until you read Date's book you're likely to just think of Fabian as some sort of crank, out of ignorance. Until you take the trouble to learn what you need to know to evaluate his arguments you have no real basis for judging him in error.
Of course, that doesn't stop most people.
KFG
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.)
Table-ized A.I.
By creating a new language, "Tutorial D", developers are excluding the other languages as much as they're including new features in the new language. Why not just add a Java package that includes the new syntax? To get anywhere in software development, even Tutorial D code will have to interoperate with existing systems and programmers with existing skills. Someone will have to code a "Tutorial D" JDBC driver, and ODBC, and all kinds of middleware that eats performance, developer time, and introduces the maintenance pitfalls of complexity. And by adding a package to an existing language, they can skip reimplementing the features of the existing language that they include in this new one, like loops, branches and character output. The effort seems as vain as the endless 19th Century conceits of inventing complete philosophical systems from scratch, to serve the reputations of egomaniacs dominating university debates. Why can't everyone just speak Object, with procedural slang and set-theoretical poetry?
--
make install -not war
I might also introduce keywords POSSIBLY and CERTAINLY that collapse tri-state logic (true, false, maybe) into boolean logic. Thus, POSSIBLY(a = 5) would be true when a is UNKNOWN but CERTAINLY(a = 5) would be false.
Date advocates a different approach - no NULL at all. Instead, he has some sort of parallel table structure; a row in one table for the value being present and in another for the value being absent. With some more complex way of constraining it so there would be no contradictory information in the tables. I don't like this approach - having no NULLs seems simpler than having two, but not once you add in the weirdness of contraints. And not once you realize many tables have multiple nullable columns. Joining so many tables together would get ridiculous quickly.
In practice NULL seems to not be a huge problem for me. Occasionally a field can either unknown or inapplicable, and I need to distinguish between the two; I have to do a kludgy thing with another field and a CHECK constraint. But for the most part, it's just an extra half second of thought when writing the logic, which isn't too bad. But it does trip newcomers. It would be worth fixing if you were designing a new relational query language from scratch.
I use PostgreSQL for all my DB stuff. Comparing it to MySQL is like comparing a mini-pickup to an 18-wheeler. PostgreSQL ANSI support is good, and it's very stable.
When I write custom apps (pretty much all I do) I write to the full capabilities of PostgreSQL. It's "man enough" to handle the biggest projects I'll likely ever see, and I'm not worried that the vendor will up and leave, since there isn't one.
In fact, PostgreSQL has had an interesting history in that the primary supporters of it have changed several times. PostgreSQL has weathered them all with grace, and remains today an excellent database package with a good, active community and quality developers.
So, I don't worry about JDBC, I don't write to cross platform, I could give a whit about Oracle or DB2 or whatever, but I don't. PostgreSQL is free, plenty good enough, and it won't go away.
Why bother trying to make my application portable?
PS: The article's example about null is stupid. Null = "I don't know". In that context, how could you include values of " 47" if you don't know what the value should be for a particular record?
I'm interested in this new DB language, if it actually offers a real benefit - but the article does a lousy job of getting me excited about it...
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Talking SQL nowadays strikes me as being like talking raw assembler. You can do it, the tools are even rather nice nowadays, but any sane developer would use a higher level wrapper.
Like for instance, Hibernate. It does serialize/reconstitute, handles nested objects and data structures, and it's very nearly as easy as programming with regular heap-allocated objects. In any big app if you didn't use some such, you'd end up reimplementing it.
I see no reason wrappers like Hibernate have to backend onto SQL and only SQL. They could as easily emit and control this "Tutorial D" language.