4 ms·

Opinion: moreSQL is real

82 points by willvarfar 15y ago

deleted 15y ago
[deleted]
dhruvbird 15y ago
You can find out more about tokutek here: http://duckduckgo.com/?q=tokutek.com http://duckduckgo.com/?q=tokutek.com http://www.quora.com/Andrew-Byde/answers/Tokutek http://www.quora.com/Andrew-Byde/answers/Tokutek
- Tokutek 15y ago
  To expand the MVCC list noted above, MySQL + TokuDB is always in MVCC as well (since version 5.0 last year). Also note that the Quora link describes Fractional Cascading. TokuDB uses Fractal Tree indexes. To learn more about Fractal Tree indexes as opposed to basic LSM, see here - http://www.tokutek.com/2011/09/write-optimization-myths-comparison-clarifications/ http://www.tokutek.com/2011/09/write-optimization-myths-comp...
deleted 15y ago
[deleted]
tom_b 15y ago
I love SQL (stay with me). I cut my SQL teeth on SQL scripts written by programmers who were mainly Java jockeys. Lots of imperative code built around getting a result set and iterating over it. I was learning relational programming by playing in SQL cmd lines. And getting massive speed-ups by pushing code back to the SQL engines and out of imperative loops. I love this style of coding - when you squint just right, it looks (a bunch) like a REPL and exploratory development. And for that last fact, I will always have a bit of a soft spot for SQL. ANSI, please. Host language interfaces on the side.
- jcromartie 15y ago
  I came here to say pretty much just this. SQL and declarative relational programming are extremely powerful. The new breed of DBs are throwing away something with a solid mathematical and theoretical foundation. In fact, I wonder if a lot of the reaction against relational databases stems from a lack of understanding of the declarative style and the underlying relational algebra. Most of the programmers I have worked with can write Java or C# code just fine, but they do just like you described when writing SQL, which makes SQL seem clunky and perform horribly. On the other hand, when you start thinking in sets, and learn to embrace the query optimizer (it does work) you can stop writing silly SQL code and write beautiful and elegant code that does exactly what you need 99% of the time. I like Ruby, Clojure, Haskell, JSON, shell scripts, and dang it I like SQL.
  - weavejester 15y ago
    I really don't like SQL. It doesn't follow the relational model and the syntax is extremely hard to parse. It was written in an era that was more worried about conserving computing resources than thinking about abstractions. I've nothing against relational databases, but I wish SQL would hurry up and die :(
    - ericmoritz 15y ago
      What would be your ideal implementation of such an abstraction?
      - weavejester 15y ago
        Something that's easy to parse, and ideally adheres to the relational model. I'm not certain if the latter can be done in a performant manner, so I'd probably settle for a few compromises if they were well argued. For example, a natural join between two tables could be represented as an S-expression: (join a b) The actual format is probably irrelevant. You could represent it as JSON or XML or some binary protocol. What would matter is that you were transferring a standard structure (i.e. a list consisting of 'join', 'a' and 'b'). Compare this to SQL where you'd actually send a raw string: SELECT * FROM a NATURAL JOIN b Although because SQL doesn't follow the relational model particularly closely, usually you'd write something more like: SELECT * FROM a JOIN b ON a.id = b.a_id Both of these statements are much harder to parse than a S-expression represented by some known format. As well as being harder to parse, it's also harder to combine SQL. For example, perhaps I want to add a selection to limit the join: (select (join a b) (= x 1)) Combining expressions in a S-expression is trivial, but in SQL it's more complex. You can't just wrap one expression in another - you'd want to extend an existing statement with a "WHERE": SELECT * FROM a JOIN b ON a.id = b.a_id WHERE x = 1 More complex expressions become a mess of subqueries, and very hard to parse. Man ORMs actually represent queries as ASTs internally and only convert them into SQL at the last moment. If we could sent relational queries directly to the database we'd save a lot of work.

82 points by willvarfar 15y ago

deleted 15y ago

[deleted]

You can find out more about tokutek here: http://duckduckgo.com/?q=tokutek.com http://duckduckgo.com/?q=tokutek.com http://www.quora.com/Andrew-Byde/answers/Tokutek http://www.quora.com/Andrew-Byde/answers/Tokutek

Tokutek 15y ago
To expand the MVCC list noted above, MySQL + TokuDB is always in MVCC as well (since version 5.0 last year). Also note that the Quora link describes Fractional Cascading. TokuDB uses Fractal Tree indexes. To learn more about Fractal Tree indexes as opposed to basic LSM, see here - http://www.tokutek.com/2011/09/write-optimization-myths-comparison-clarifications/ http://www.tokutek.com/2011/09/write-optimization-myths-comp...

deleted 15y ago

[deleted]

tom_b 15y ago

I love SQL (stay with me). I cut my SQL teeth on SQL scripts written by programmers who were mainly Java jockeys. Lots of imperative code built around getting a result set and iterating over it. I was learning relational programming by playing in SQL cmd lines. And getting massive speed-ups by pushing code back to the SQL engines and out of imperative loops. I love this style of coding - when you squint just right, it looks (a bunch) like a REPL and exploratory development. And for that last fact, I will always have a bit of a soft spot for SQL. ANSI, please. Host language interfaces on the side.

jcromartie 15y ago
I came here to say pretty much just this. SQL and declarative relational programming are extremely powerful. The new breed of DBs are throwing away something with a solid mathematical and theoretical foundation. In fact, I wonder if a lot of the reaction against relational databases stems from a lack of understanding of the declarative style and the underlying relational algebra. Most of the programmers I have worked with can write Java or C# code just fine, but they do just like you described when writing SQL, which makes SQL seem clunky and perform horribly. On the other hand, when you start thinking in sets, and learn to embrace the query optimizer (it does work) you can stop writing silly SQL code and write beautiful and elegant code that does exactly what you need 99% of the time. I like Ruby, Clojure, Haskell, JSON, shell scripts, and dang it I like SQL.
- weavejester 15y ago
  I really don't like SQL. It doesn't follow the relational model and the syntax is extremely hard to parse. It was written in an era that was more worried about conserving computing resources than thinking about abstractions. I've nothing against relational databases, but I wish SQL would hurry up and die :(
  - ericmoritz 15y ago
    What would be your ideal implementation of such an abstraction?
    - weavejester 15y ago
      Something that's easy to parse, and ideally adheres to the relational model. I'm not certain if the latter can be done in a performant manner, so I'd probably settle for a few compromises if they were well argued. For example, a natural join between two tables could be represented as an S-expression: (join a b) The actual format is probably irrelevant. You could represent it as JSON or XML or some binary protocol. What would matter is that you were transferring a standard structure (i.e. a list consisting of 'join', 'a' and 'b'). Compare this to SQL where you'd actually send a raw string: SELECT * FROM a NATURAL JOIN b Although because SQL doesn't follow the relational model particularly closely, usually you'd write something more like: SELECT * FROM a JOIN b ON a.id = b.a_id Both of these statements are much harder to parse than a S-expression represented by some known format. As well as being harder to parse, it's also harder to combine SQL. For example, perhaps I want to add a selection to limit the join: (select (join a b) (= x 1)) Combining expressions in a S-expression is trivial, but in SQL it's more complex. You can't just wrap one expression in another - you'd want to extend an existing statement with a "WHERE": SELECT * FROM a JOIN b ON a.id = b.a_id WHERE x = 1 More complex expressions become a mess of subqueries, and very hard to parse. Man ORMs actually represent queries as ASTs internally and only convert them into SQL at the last moment. If we could sent relational queries directly to the database we'd save a lot of work.