Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
If there was implementation of query language based on http://en.wikipedia.org/wiki/FLWOR on PostgreSQL backend - I'd have switched immediately.
PostgreSQL and the SQL standards process
Posted Sep 21, 2011 19:31 UTC (Wed) by dskoll (subscriber, #1630)
FLWOR looks like the "best" [sic] of both SQL and XML... a nastier horror I could not imagine. :)
Posted Sep 21, 2011 19:45 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
FLWOR is as clear as day compared to that.
Though I'm not against even better language, FLWOR should be considered just as a nice guide about how query languages should be written. In any case, it's a bit XML-specific and should be extended for relational data with features like explicit joins instead of nested loops.
Posted Sep 21, 2011 19:55 UTC (Wed) by dskoll (subscriber, #1630)
Have you ever tried recursive queries in SQL with CTEs?
Ugh, no. :) I guess my use of SQL is not at that level. I agree that such queries are unreadable piles of evil, and predicting how they will perform is like reading a crystal ball.
Posted Sep 21, 2011 19:36 UTC (Wed) by jeremiah (subscriber, #1221)
Posted Sep 21, 2011 21:46 UTC (Wed) by robert_s (subscriber, #42402)
"If there was implementation of query language based on http://en.wikipedia.org/wiki/FLWOR on PostgreSQL backend - I'd have switched immediately."
I'm not convinced we need a whole query "language" at all. The huge majority of database use is done on behalf of larger applications written in a different language. Why make developers learn another half-functional language just to be able to express their query intentions? I'd be far more interested in mechanisms to expose the querying possibilities in a developer's "native" language, which is why I found Berkus' sentence
"However, it's more likely that we'll be working more on direct language interfaces in the future instead"
Posted Sep 21, 2011 22:03 UTC (Wed) by raven667 (subscriber, #5198)
I guess that's already the case for a lot of the newer databases like Hadoop where each has its own custom API and special storage/transaction/replication semantics
Posted Sep 21, 2011 23:56 UTC (Wed) by zlynx (subscriber, #2285)
The backend code to implement it is awful, but the user side of it is great.
Posted Sep 22, 2011 0:58 UTC (Thu) by raven667 (subscriber, #5198)
I suppose that's already the case somewhat with proprietary extensions and incompatibilities between different SQL databases but I worry that it would be harder to handle and workaround if there were less compatibility between applications and databases as provided by the SQL standard.
Posted Sep 22, 2011 1:24 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
LINQ is just a mechanism which can be used to create DSLs to query data.
Posted Sep 22, 2011 5:55 UTC (Thu) by smurf (subscriber, #17840)
Right now, that common representation is text and SQL, plus (sometimes) a server-specific method to prepare statements to prevent having to transcode and quote data.
Replace that with XML or whatever all you want. Doesn't buy you anything. You still have to assemble a textual string on one end and analyze it on the other side.
Three choices here:
* stay with SQL. It mostly works, people are used to it, you can do interesting stuff with it in any programming language whatsoever. Downside: you still need server-specific code for more complicated queries and for schema.
* agree on a common high-level API for queries, and possibly for schema queries/changes. Downside: who'd do the work and who'd agree on the result? The commercial vendors? Hardly.
* agree on a common binary data stream between client and server. Same downside, plus doesn't work for embedded servers.
Posted Sep 25, 2011 23:06 UTC (Sun) by jberkus (subscriber, #55561)
The thing is, we *already* have that. 80% of applications out there which interface with a SQL database use an ORM or similar high-level interface, and few ORMs support more than a couple of DBMSes. Developers are not using SQL to push data today.
Frankly, if database geeks took control of the ORMs and gave developers a user-friendly interface in their own language, it would be both better for developers and better for the databases. We could make sure that these interfaces *do the right thing* as far as database interfacing is concerned. The whole path of Call ORM --> Generate SQL String --> Parse SQL String --> Communicate Binary Protocol has at least one too many steps in it.
Couch and Mongo have gone partway there with JSON, but they're still essentially using intermediate query languages. And worse, BSON isn't even a standard anywhere, so it's completely non-portable.
Of course, we want to still support SQL as a direct interface for database geeks to do "advanced" work. But that's only about 10% of the database interaction out there. And I say this as a SQL expert.
Posted Sep 26, 2011 2:48 UTC (Mon) by raven667 (subscriber, #5198)
As you say, if each database engine wrote their own custom ORM then developers could write better queries and get better results more safely but it would increase lock-in which is not an unmitigated positive.
Posted Sep 21, 2011 23:59 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
That's why a separate fully-analyzable language is needed. FLWOR is a nice example because it's functional and fully reference-transparent. So optimization engine can backtrack through definitions and get the complete picture of what's happening. And then use tried-and-true join optimizations.
Posted Sep 22, 2011 19:43 UTC (Thu) by iabervon (subscriber, #722)
Posted Sep 22, 2011 20:08 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
Explicit query-construction API should express roughly the same ideas as the textual query representation.
Posted Sep 22, 2011 20:14 UTC (Thu) by dlang (✭ supporter ✭, #313)
different languages (and for that matter, different libraries for a single language) will want to represent the data in different ways.
it would be good to have a standard format that could eliminate the SQL injection type of vulnerability, but it's hard to think of anything that can take an arbitrary byte stream and use it in an arbitrary place in the statement, while still allowing multiple statements in one blob that would eliminate the problem
Posted Sep 30, 2011 18:43 UTC (Fri) by Baylink (subscriber, #755)
The answer is "you've never been 400ms away from your database engine, have you"?
Yes, the architecture of SQL is the way it is for a reason. You young whippersnappers (:-) have never run a database engine with an API interface across even a LAN, much less a WAN, so you forget both halves of the latency term of the equation, much less the data reduction of having *all* the intermediate work happen inside the server.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds