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."
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.
Is the sole issue what it can and can't do? what if there was an easier way to express joins? Most queries I write have more joins than actual query. Even though the database already knows the relationships between the tables.
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.
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.
Yuck, you would never Want to do that. That's what relationships and foreign keys are for. You wouldn't populate your id's across columns, you put them in a new table, one row each, with an foreign key linking them back to main table.
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
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
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 take it logic puzzles were never your strong point.
0.00 != null
Zero is implying that there is a value there and that it is in fact the number zero. Null would imply that no value ever existed, zero or otherwise.
In all of my db designs I try to avoid nulls unless absolutely neccessary. A typical situation where nulls are unavoidable would be in an end date field( no end date as of yet). You also usually get nulls back when doing outer joins.
Remember though that null != 0 != ''. Null is the complete absence of a value.