5 ms·

Standard SQL sucks and this is Why... I think standard SQL is not the solution to many of these problems. What we need is something new or in this case old, th

Standard SQL sucks and this is Why... I think standard SQL is not the solution to many of these problems. What we need is something new or in this case old, that is built for such queries. What do I mean, well let’s look through their examples reimplemented in qsql and I’ll show you how much shorter and simpler this could be: http://www.timestored.com/b/standard-sql-sucks-and-this-is-why/ http://www.timestored.com/b/standard-sql-sucks-and-this-is-w... On another note I actually love jooq the java library and have reimplemented something similar for qSQL. If anyone from jooq is reading, I've made a free java snippet runner called jpad.io that I would be interested seeing used with jooq. I think your customers may like it.

lukaseder 10y ago
You're probably right, and at the time SQL was "invented" (and standardised), a lot of people were right too. They wanted QUEL, they got SQL. But hey, the presentation (linked from the article) got a slide for you: http://de.slideshare.net/LukasEder1/10-sql-tricks-that-you-didnt-think-were-possible/35 http://de.slideshare.net/LukasEder1/10-sql-tricks-that-you-d... Sorry :)
- RyanHamilton 10y ago
  "SQL is the worst form of database querying, except for all the other forms." LOL. As long as many people believe things like that, innovators can go out, learn new tools that will give them 10x more productivity and be able to make better things faster, delivering more business value. In the words of Paul Graham http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html "But I don't expect to convince anyone (over 25) to go out and learn Lisp. The purpose of this article is not to change anyone's mind, but to reassure people already interested in using Lisp-- people who know that Lisp is a powerful language, but worry because it isn't widely used. In a competitive situation, that's an advantage. Lisp's power is multiplied by the fact that your competitors don't get it."
  - lukaseder 10y ago
    I know that article, it's excellent. And I like Paul Graham's point of view, usually. But that article addresses (and will ever only address) the "elite". Like QUEL, which didn't make it. SQL did. This doesn't have too much to do with innovation. It has everything to do with product-market-fit. SQL is the technology for the masses. QUEL (or something else more recent, very lean and sophisticated) is the technology for the elite. But why doesn't the "elite thing" go mainstream? Wrong product-market-fit.
    - RyanHamilton 10y ago
      Could JOOQ be considered a kind of language for the "elite" in that respect? Those that want the extra power to write queries quickly with type safety etc instead of manually crafting the java/sql interface. That extra speed was one of the reasons I looked at JOOQ. I do like your idea, I guess I've made similar judgement calls in the past. I know some mainstream languages for the popularity power it gives me but for use cases where I think I can find a technical advantage I seek out new ideas/languages for that edge.
      - lukaseder 10y ago
        Hmm, I haven't thought about it this way. But I don't think so. While jOOQ does enable a lot of "advanced" language features (like row level type safety across languages, and streaming of such tuples in Java 8 Streams), I still think that it mainly addresses the "masses" - at least those "masses" that profit from a slightly more sophisticated SQL integration than just boring CRUD. The examples exposed in the linked article certainly aren't every day examples for the masses. But I personally absolutely agree with you. There are technologies that do enable orders of magnitude in development efficiency. For instance, I'd love to work with Clojure and Datomic. I have a huge respect for Rich Hickey. But I don't think that everyone should, or ever will, use these technologies. In the end, when you have to do recruiting, from your local market, and you need 100 developers, choose Clojure and you'll be screwed.
    - epalmer 10y ago
      QUEL's problem was not that it was for the elite but that Relational Technology (later named Ingres) did not have any sense on how to market and sell Ingres RDBMS and promote QUEL. Oracle's strength has always been marketing and sales and they started to take over the market quickly from Ingres in the first few years of commercial RDBMS. Yes there were other players in the market at the time but in the very early days it really was Ingres versus Oracle. For those of us that are older we know that Ingres was a result of Dr. Michael Stonebraker's work at Berkeley. There was at the time a university project known as Ingres and a commercial product known as Ingres. Yes postgres is what happened at Berkeley after Ingres. I always loved QUEL and was downright pissed when it was ignored over the inferior SQL.
- saosebastiao 10y ago
  People actually wanted QUEL? There is nothing of value there. Maybe this is a hindsight bias, but it was less powerful than SQL in pretty much every way possible. The only thing SQL got irrevocably wrong from the start was null handling which forced us into non-intuitive ternary logic that couldn't be deprecated because of backwards compatibility.
treebeard901 10y ago
SQL gets a bad reputation from programmers that have a strictly procedural understanding of problem solving. When you are dealing with large amounts of data a SET based approach to data retrieval will likely be the better solution. The problem often comes from trying to bridge the procedural world with the set based world.
- akavi 10y ago
  SQL also gets a bad reputation from programmers that have a SET based approach to data too, because it's horribly uncomposable. When I try and solve a problem with SQL, it's generally trivial to produce a solution in relational algebra pseudocode , and convert that in turn into a deeeeeeeply nested, horribly nonperformant almost SQL query. Then I have to go through to try and unnest it, fix all the little "gotchas" involving "GROUP BY" and "HAVING" and implicit aliasing, and somehow make it performant (Admittedly, that last one is usually the DB optimizer's fault.) Relational algebra is a beautiful way to answer many questions. The issue is SQL isn't a very good way of writing it.
  - dsp1234 10y ago
    and convert that in turn into a deeeeeeeply nested I find that CTEs are the solution to deep nesting. There are very few times that I haven't been able to reduce the amount of nesting down to 2 levels (just the a single query with a subquery as part of an exists or something). That's obviously a problem if you don't have access to CTEs (mysql) or CTEs are an optimization boundary (postgres), but if you're working with a product that does not have those issues, then CTEs can really clean up a lot of sql.

lukaseder 10y ago

You're probably right, and at the time SQL was "invented" (and standardised), a lot of people were right too. They wanted QUEL, they got SQL. But hey, the presentation (linked from the article) got a slide for you: http://de.slideshare.net/LukasEder1/10-sql-tricks-that-you-didnt-think-were-possible/35 http://de.slideshare.net/LukasEder1/10-sql-tricks-that-you-d... Sorry :)

RyanHamilton 10y ago
"SQL is the worst form of database querying, except for all the other forms." LOL. As long as many people believe things like that, innovators can go out, learn new tools that will give them 10x more productivity and be able to make better things faster, delivering more business value. In the words of Paul Graham http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html "But I don't expect to convince anyone (over 25) to go out and learn Lisp. The purpose of this article is not to change anyone's mind, but to reassure people already interested in using Lisp-- people who know that Lisp is a powerful language, but worry because it isn't widely used. In a competitive situation, that's an advantage. Lisp's power is multiplied by the fact that your competitors don't get it."
- lukaseder 10y ago
  I know that article, it's excellent. And I like Paul Graham's point of view, usually. But that article addresses (and will ever only address) the "elite". Like QUEL, which didn't make it. SQL did. This doesn't have too much to do with innovation. It has everything to do with product-market-fit. SQL is the technology for the masses. QUEL (or something else more recent, very lean and sophisticated) is the technology for the elite. But why doesn't the "elite thing" go mainstream? Wrong product-market-fit.
  - RyanHamilton 10y ago
    Could JOOQ be considered a kind of language for the "elite" in that respect? Those that want the extra power to write queries quickly with type safety etc instead of manually crafting the java/sql interface. That extra speed was one of the reasons I looked at JOOQ. I do like your idea, I guess I've made similar judgement calls in the past. I know some mainstream languages for the popularity power it gives me but for use cases where I think I can find a technical advantage I seek out new ideas/languages for that edge.
    - lukaseder 10y ago
      Hmm, I haven't thought about it this way. But I don't think so. While jOOQ does enable a lot of "advanced" language features (like row level type safety across languages, and streaming of such tuples in Java 8 Streams), I still think that it mainly addresses the "masses" - at least those "masses" that profit from a slightly more sophisticated SQL integration than just boring CRUD. The examples exposed in the linked article certainly aren't every day examples for the masses. But I personally absolutely agree with you. There are technologies that do enable orders of magnitude in development efficiency. For instance, I'd love to work with Clojure and Datomic. I have a huge respect for Rich Hickey. But I don't think that everyone should, or ever will, use these technologies. In the end, when you have to do recruiting, from your local market, and you need 100 developers, choose Clojure and you'll be screwed.
  - epalmer 10y ago
    QUEL's problem was not that it was for the elite but that Relational Technology (later named Ingres) did not have any sense on how to market and sell Ingres RDBMS and promote QUEL. Oracle's strength has always been marketing and sales and they started to take over the market quickly from Ingres in the first few years of commercial RDBMS. Yes there were other players in the market at the time but in the very early days it really was Ingres versus Oracle. For those of us that are older we know that Ingres was a result of Dr. Michael Stonebraker's work at Berkeley. There was at the time a university project known as Ingres and a commercial product known as Ingres. Yes postgres is what happened at Berkeley after Ingres. I always loved QUEL and was downright pissed when it was ignored over the inferior SQL.
saosebastiao 10y ago
People actually wanted QUEL? There is nothing of value there. Maybe this is a hindsight bias, but it was less powerful than SQL in pretty much every way possible. The only thing SQL got irrevocably wrong from the start was null handling which forced us into non-intuitive ternary logic that couldn't be deprecated because of backwards compatibility.

treebeard901 10y ago

SQL gets a bad reputation from programmers that have a strictly procedural understanding of problem solving. When you are dealing with large amounts of data a SET based approach to data retrieval will likely be the better solution. The problem often comes from trying to bridge the procedural world with the set based world.

akavi 10y ago
SQL also gets a bad reputation from programmers that have a SET based approach to data too, because it's horribly uncomposable. When I try and solve a problem with SQL, it's generally trivial to produce a solution in relational algebra pseudocode , and convert that in turn into a deeeeeeeply nested, horribly nonperformant almost SQL query. Then I have to go through to try and unnest it, fix all the little "gotchas" involving "GROUP BY" and "HAVING" and implicit aliasing, and somehow make it performant (Admittedly, that last one is usually the DB optimizer's fault.) Relational algebra is a beautiful way to answer many questions. The issue is SQL isn't a very good way of writing it.
- dsp1234 10y ago
  and convert that in turn into a deeeeeeeply nested I find that CTEs are the solution to deep nesting. There are very few times that I haven't been able to reduce the amount of nesting down to 2 levels (just the a single query with a subquery as part of an exists or something). That's obviously a problem if you don't have access to CTEs (mysql) or CTEs are an optimization boundary (postgres), but if you're working with a product that does not have those issues, then CTEs can really clean up a lot of sql.