An Alternative to SQL? 505
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? (Score:4, Interesting)
Re:Who remembers Knowledgeman? (Score:3, Interesting)
Re:Who remembers Knowledgeman? (Score:5, Funny)
Re:Who remembers Knowledgeman? (Score:5, Funny)
I take it logic puzzles were never your strong point.
Re:Who remembers Knowledgeman? (Score:3, Interesting)
shortcomings to sql? (Score:4, Insightful)
I was about to ask the same thing. (Score:5, Insightful)
Re:I was about to ask the same thing. (Score:5, Insightful)
I agree sql could be better but the more complexity you add the more bullshit code I'll have to figure out what programmers were doing when I'm hired to fix their code. The company I currently work for has stored procedures that are over 4,000,000 lines (total) for report generation. Amazing how difficult it is to debug and work with. Especially since it was done in Transact SQL. I'm probably biased toward PL/SQL because I learned it first but it is so much easier to code in than Transact. (I have about 5-6 years of working in TSQL and about 7-8 in PL/SQL)
Re:I was about to ask the same thing. (Score:3, Insightful)
Re:I was about to ask the same thing. (Score:3, Insightful)
Re:I was about to ask the same thing. (Score:3, Interesting)
Am I missing a requirement? This seems like it shouldn't be an issue.
Re:I was about to ask the same thing. (Score:5, Insightful)
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.
Re:shortcomings to sql? (Score:3, Insightful)
probably something along those lines, that it would be easier to do some things and easier to avoid problems.
Re:shortcomings to sql? (Score:4, Interesting)
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.
It's not about optimization... (Score:5, Informative)
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.
Re:It's not about optimization... (Score:5, Informative)
INSERT: A shorthand syntax is available for INSERT. The following:
May also be specified as:
Or:
The lattermost syntax is intended to be vaguely evocative of the "increment by 'n' and assign" operator found in C, C++, Java, and other languages. DELETE: A shorthand syntax is available for DELETE. The following:
May also be specified as:
The following:
May also be specified as:
Or:
The use of "-=" is intended to be vaguely evocative of the "decrement by 'n' and assign" operator found in various popular programming languages. UPDATE: A shorthand syntax is available for UPDATE. The following:
May also be specified as:
Or:
Or, because SET is optional:
Comments: Comments are specified using conventional C++ and Java syntax. Eg:
More info and examples here. [sourceforge.net]
Re:shortcomings to sql? (Score:3)
You would be surprised at how much your database knows about itself, and what it is able to do with that information in optimizing your queries.
But then I am sure you know all this better than me, since you sound like the DBA here, and I just rely on highler level stuff.
Re:shortcomings to sql? (Score:4, Insightful)
sql doesn't cut it because it's too high level. trying to do anything somewhat complicated in sql leads to headache and turmoil. the big problem is that there is no lower level interface to communicate to your database server with.. all you can do is hand it sql statements and get your results.
why bother writing a better sql? how about a low level object based api. use whatever language your client is already written in (so long as its oo). fuck learning another busted ass super high level language.. give me objects, methods, exceptions, etc.
Re:shortcomings to sql? (Score:4, Informative)
you were born too late (Score:3, Insightful)
Tons of opportunities there for low-level access to your data. Of course, there's a reason that all those database management systems were abandoned for a 'busted ass super high level language'. It's because they sucked to maintain, they didn't evolve well as business requirements changed over time, and if you had the *most* basic of business questions - you'd never get an answer without a month of
Re:shortcomings to sql? (Score:3, Insightful)
Joins are a big pain in the butt, and the case statements get so convoluted I feel like I'm writing LISP.
Re:shortcomings to sql? (Score:4, Insightful)
Maybe try an object-oriented database (I hear ObjectStore is good), or an associative database (BerkeleyDB), or an XML database (Sleepycat has one).
Relational databases aren't the only game in town, they are just the most popular and therefore:
I think he's trying to say: (Score:5, Interesting)
Compare the symbolic forms:
Example, theta join [wikipedia.org]
And the implementation in SQL:
SQL join example [1keydata.com]
Specifically in Tutorial D (and hence Rel) you would do this:And subsequently do shit with T1. That's it.
Re:I think he's trying to say: (Score:3, Insightful)
for example:
I want the name field from a if it's id is in b.
In relational algebra,
PROJECT[A.name](THETA_JOIN[A.id=B.id](A , B))
or
p[A.name](A |X|[A.id=B.id] B)
Sorry, ascii sucks.
In SQL
SELECT DISTINCT A.name FROM A,B WHERE A.id=B.id;
I find the SQL version to be more readable, etc. The same functionality is provided by both and is easily transferable.
cartesian production becomes SELECT * FROM A,B
natural joi
I think with Rel... (Score:3, Informative)
By not trying to be like SQL, and more like {T,PL}SQL, I think they get the freedom they need.
SQL is a poor relational data model implementation (Score:4, Informative)
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.
Re:shortcomings to sql? (Score:4, Informative)
-"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."
-"rather arbitrary habit of allowing nested queries in some places but not others, for instance"
Re:shortcomings to sql? (Score:4, Insightful)
You only need to learn about null comparisons once, and nulls are extremely valuable when you get into eliminating rows from a result sets based on matches from data in other tables.
Combining a left outer join with a search condition where a primary key is null from the joined table is a quick and dirty way to scrub records where there's a match in the joined table, and would be impossible without the concept of nulls.
Re:shortcomings to sql? (Score:4, Interesting)
Re:NULL is problematic. (Score:5, Insightful)
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.
Re:shortcomings to sql? (Score:4, Informative)
Null was meant to take the place of all the hack jobs that were used in older databases to signify non-value, NaN and so on.
Part of using SQL in the manner that it is, is that you get what you ask for. You dont get what some programmer *thinks* you want. Because at some point you may want something else. I really dont want a computer to guess at what I really want. I want it to tell me what it knows.
Re:shortcomings to sql? (Score:3, Interesting)
[...]
Null was meant to take the place of all the hack jobs that were used in older databases to signify non-value, NaN and so on.
Yes, and this is a big part of the point of D. The authors assert that the way that current DB structures are designed leads to bad design- that there shouldn't be nulls. They have a lot of good reasons for this belief, and it is true that SQL leads people to rely on nulls in cases is a sort of synergystic nigh
SQL is good for some things, but not for others (Score:2, Insightful)
Re:SQL is good for some things, but not for others (Score:2)
Re:SQL is good for some things, but not for others (Score:5, Interesting)
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: (Score:3, Interesting)
Re:shortcomings to sql? (Score:3, Informative)
Re:shortcomings to sql? (Score:5, Informative)
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.
Comment removed (Score:4, Interesting)
SQL joins. (Score:4, Informative)
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.
Re:shortcomings to sql? (Score:5, Informative)
Really, 95% of the problems that Chris Date and Hugh Darwen have with SQL revolve around an incomplete relational treatment of data. For example, by definition, a relation cannot have duplicate tuples (rows), but a table in SQL *can*. Also, columns in a table should not have a left-to-right ordering, which they do have in SQL (they should be thought of only as attributes, not positionally). Also, SQL fails to completely implement closure, where the result of *any* relational expression becomes a relation which can be in itself modified by any other relational expression. Also, SQL fails to provide a truly extensible approach to user-defined datatypes or domains.
Etc... etc... there are many other small kvetches and some big ones with SQL. Read the Darwen docs, and you will see some interesting things.
Essentially, the problem comes down to an ad-hoc experimental language (SQL), which was only intended as a temporary solution, which was then taken over and re-designed by a committee (ANSI).
Lotus Domino... (Score:4, Insightful)
What's the use? (Score:4, Insightful)
Re:What's the use? (Score:5, Insightful)
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.
Re:What's the use? (Score:5, Interesting)
Please, please, there must be a sane way to query data from a highly normalized database.
Re:What's the use? (Score:3, Insightful)
Call me crazy, but if you have a 25-way join, don't you think you have bigger problems than your querying language? Maybe the person that is asking for the join needs to change their business processes.
Re:What's the use? (Score:3, Informative)
Re:What's the use? (Score:5, Informative)
- Call me crazy, but if you have a 25-way join, don't you think you have bigger problems than your querying language? Maybe the person that is asking for the join needs to change their business processes.
Go work in a big ERP system. We use PeopleSoft and one of our tech has been debugging an AP (maybe GL?) query that's not working as expected and it's a 20 union beast. That's delivered too, not some home-rolled query. I'm sure there are worse queries out there lurking in the hearts of our system too.As for just changing our business process, well that's fine in an ideal world, but in practical reality it ain't gonna' happen without an act of Congress. You have to have someone who knows "best-practice" methodolgy come up with a new process, get sign-off across multiple departments and our auditing company so our banks and major vendors are okay with the changes, and then begin process training and roll-out. And that's for a small, private company; if you're public and have to add SOX compliance to the mix...well, good luck.
Re:What's the use? (Score:3, Interesting)
Prolog! [fi.upm.es] Logic languages are well suited to relational data, where a table maps to a predicate. The logic programming community spent a couple decades trying to convert everybody from SQL and nobody listened.
I was about to say SQL is like COBOL, but SQL seems to be even more persistent so perhaps it's not as flawed.
Re:What's the use? (Score:3, Interesting)
Prolog! Logic languages are well suited to relational data, where a table maps to a predicate. The logic programming community spent a couple decades trying to convert everybody from SQL and nobody listened.
Funny you should mention that. I'm now working on a program that takes user queries (from a Perl program), converts them to Prolog, and finds the solutions against a SQL database.
It seems to work great, so far.
Re:What's the use? (Score:3, Interesting)
Amen, I HEAR you, brother!
I've had to write "dynamically generated" queries - and they are a TOTAL MESS, with lots of crappy if statements and string appends...
300 lines of code to properly parse a search page response, to generate a 20-line query that executes against 5 tables.
Ugh.
Re:What's the use? (Score:3, Insightful)
Most people lack the suficient skills to program good DB applications. And they don't find anybody with the DB skills to help on the backend.
This is where most of the issues come into play. Get a DBA that knows what they are doing.
SQL has shortcomings...is this news? (Score:3, Insightful)
Re:SQL has shortcomings...is this news? (Score:3, Insightful)
Keep in mind, the definition of "good" will vary from group to group. Hobbyists may want something that is interesting to play with, that will allo
Re:SQL has shortcomings...is this news? (Score:4, Informative)
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
The shortcomings of SQL (Score:5, Insightful)
Re:The shortcomings of SQL (Score:4, Insightful)
SQL will be around for a while still, because it's "good enough" and "already known" and there are lots of "legacy apps using it" and the new stuff is immature. I have trouble convincing people that transactions are important, that joins really should be done in the server, that they shouldn't create attributes named "value1" and "value2" just because they currently only have two,
Sure, I want a new language, I wouldn't mind learning it, heck, I wouldn't mind writing it. But the problem is convincing enough people that what they have isn't good enough.
Re:The shortcomings of SQL (Score:4, Insightful)
In the hacker world, it's not about pretty/good solutions, it's about making a problem go away quickly so you can move on to the next problem. It's all about writing one-time scripts in whatever language you know, not learning another language unless you're bored or can't solve your problem with what you already know
dont think so (Score:5, Insightful)
Heh (Score:5, Funny)
Try proposing to your boss to replace your mySQL database with "Tutorial D" for... no good reasons? Will happen. Soon. Right?
Re:Heh (Score:3, Funny)
I gotta say ... (Score:5, Insightful)
sounds a lot like
"C is sloppy and unpredictable; Pascal is a correct programming language."
Comment removed (Score:4, Insightful)
Re:I gotta say ... (Score:3, Interesting)
SQL vs. Tutorial D (or any of the other "mor
Me and my buggywhips (Score:4, Funny)
Re:Me and my buggywhips (Score:5, Funny)
Ever heard of TSQL? (Score:5, Interesting)
Re:Ever heard of TSQL? (Score:3, Insightful)
Let's say that tomorrow MySQL adopts Tutorial D. Ok, so you are going to write code that talks to MySQL and you think about Tutorial D.... well, MySQL still talks SQL, and it turns out that so does everything else. Someday you may want to switch databases because suddenly DB2 is all the rage. If you use Tutorial D, you can't switch.
Any move away from SQL would have to be a broad industry move or would have t
Re:Ever heard of TSQL? (Score:3, Informative)
Don't forget microsoft's X-Query (Score:3, Interesting)
Re:Don't forget microsoft's X-Query (Score:5, Informative)
Re:Don't forget microsoft's X-Query (Score:3, Insightful)
Perhaps it is interesting. (Score:3, Insightful)
Worth ditching SQL? (Score:2, Insightful)
SQL has worked so far but if Tutorial D really is better then bring it on.
I've gotten over SQL the "short commings" though
Not a replacement language... (Score:5, Insightful)
Re:Not a replacement language... (Score:3, Interesting)
Re:Not a replacement language... (Score:3, Funny)
Even if I couln't see your UID, that phrase above would give you away as being "new around here".
This could mean... (Score:4, Funny)
Tutorial D... (Score:3, Interesting)
The reaons for wanting a change from SQL I agree with, but Tutorial D you'll never catch me using.
We need something to combine the power and speed of SQL query syntax with the nested filtering ability of XPath, yet doesn't require the entire DOM to be in memory to work.
Predicate Imputation (Score:3, Informative)
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) [clusty.com] or multi-relational data mining [clusty.com] via inductive logic programming [clusty.com].
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 [sourceforge.net]. 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 [sourceforge.net].
Sourceforge project page (Score:3, Informative)
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. "
Link to the actual project (Score:3, Informative)
Benefits of alternative languages (Score:4, Insightful)
For those interested, the paper describing this language (linked to from the article) is available here [sourceforge.net]. 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.
Null is not Zero in SQL (Score:4, Insightful)
"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.
RPG (Score:3, Funny)
Null=Null is Null, except Group in Group By (Score:3, Funny)
Sounds like... (Score:3, Funny)
Jack Black and some bald dude have gotten into databases?
My work on this (Score:4, Interesting)
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.
in anger??? (Score:3, Funny)
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?
No new languages needed. (Score:5, Insightful)
Not the first. (Score:3, Informative)
It is not true that no one ever did anything with Date's and Darwen's ideas on a relational language. Check, for instance, the category I edit [dmoz.org.] at the Open Directory [dmoz.org.], or even Darwen's own The Third Manifesto [thethirdmanifesto.com] website with its list of projects.
Probably the poster is confused about the nature of Tutorial D. As it names indicate, it is but an example of a possible 'D', and one targeted at instruction at that. This accounts for its COBOLishness. It is possible to implement a non-Tutorial D that is completely faithful to the Relational Model and the Third Manifesto, yet has a distinct flavour.
For example, Alphora Dataphor implements D4, which was a compliant D until having had to incorporate SQL NULLs quite recently, and it has a Pascal flavour to it; Opus and Duro are C-like; there was a guy wanting to implement a C#-like D-flat language; Alfredo Novoa is implementing Tutorial D itself in MS.Net; and so on.
By the way, it is interesting that until now the more ambitious projects, that seem to be Alphora's and Mr Novoa's, are in MS .Net. Time for the free software community to rise to the challenge!
Vendor Lock-in is a myth for me (Score:5, Informative)
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...
Re:Vendor Lock-in is a myth for me (Score:3, Insightful)
The wacky part is using NULLs as a primary excuse to develop another language. First off - NULLs are optional in relational databases. Don't like them? Fine, don't use them. declare your columns 'NOT NULL'. It's that easy.
Secondly, most work-arounds for unknown data suck:
* The easy ones involve keeping an 'unknown' value row in most of yo
If you're sensible, you're never touching raw SQL (Score:5, Informative)
Like for instance, Hibernate [hibernate.org]. 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.
Re:Grammar? (Score:2, Funny)
Re:Grammar? (Score:3, Informative)
Re:Grammar? (Score:3, Funny)
Re:sql sucks (Score:3, Informative)
Re:sql sucks (Score:3, Interesting)
All that being said, the problem with Hibernate and any other SQL generator is very simple. They are not themselves querying and acce
Re:Any query language is going to be ugly... (Score:4, Interesting)
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.)