4 ms·

I'm not sure the "Relational Model" is even a great conceptual model for common business or analytical processing. I think SQL is ugly because the model is a p

I'm not sure the "Relational Model" is even a great conceptual model for common business or analytical processing. I think SQL is ugly because the model is a poor fit; if the model was solid, a clean syntax would follow naturally. As for alternatives, MDX has superseded it for core "pivot table" analytics. For application processing, it seems modern document/hierarchical databases are good for many transactional needs. What modern relational databases have... is a very intuitive abstract storage model. That's awesome. We've been working on an alternative "navigational model" (inspired from CODASYL and ORMs) based on this storage model. Our experimental query language is at http://htsql.org http://htsql.org Our critique of SQL is at http://htsql.org/doc/overview.html#why-not-sql http://htsql.org/doc/overview.html#why-not-sql

lukaseder 13y ago
I'm sure you'll agree with Stonebraker's recent (actually, not so recent) claims that the relational model is "all wrong": http://blog.jooq.org/2013/08/24/mit-prof-michael-stonebraker-the-traditional-rdbms-wisdom-is-all-wrong/ http://blog.jooq.org/2013/08/24/mit-prof-michael-stonebraker... htsql seems very interesting. I should soon blog about your product and critique. Have you been publishing elsewhere?
- bcoates 13y ago
  That's not complaining about the relational model at all, he's complaining about implementation details of common RDBMSes being obsolete, as they're based on row-oriented storage, slow disks, small memory, and limited concurrency. Things like Amazon Redshift are still relational but make radically different decisions on most of those points. Edit: that talk is well worth reading, btw. I wonder why he completely ignores flash though?
- GFischer 13y ago
  Thanks for linking to that talk, it deserves a submission all of its own.
  - pkj 13y ago
    Absolutely. Very interesting talk. Definitely deserves a submission. BTW, the person asking the last couple of questions is Ed Bugnion, one of the co-founders of VMWare. He is a faculty now at EPFL.
    - lukaseder 13y ago
      Interesting, I didn't know that!
  - lukaseder 13y ago
    I actually submitted it, but it didn't get too much traction...
- MichaelGG 13y ago
  Actually the title is "The Traditional RDBMS Wisdom is All Wrong". He's arguing against multithreaded systems in favour of a partitioned OLTP platform like H-Store (VoltDB). I didn't see anything about the relational model being "all wrong". It works well for lots of scenarios, and turning it into a KV store is also straightforward. As far as SQL, I think people agree it's not the best query language. QUEL may have won, but Stonebraker says[1]: "The only reason SQL won in the marketplace was because IBM released DB2 in 1984 without changing the System R query language." 1: http://iggyfernandez.wordpress.com/2011/12/23/nocoug-journal-interview-professor-stonebraker/ http://iggyfernandez.wordpress.com/2011/12/23/nocoug-journal...
chris_wot 13y ago
Are you criticising the relational model, or SQL? You seem to be contradicting yourself with your own language, which you claim works well with relational databases (ergo, works well with the relational model).
- clarkevans 13y ago
  The relational query model (it's operators and set algebra) is a poor fit for common business inquiries. I view SQL as a practical syntax for encoding relational queries; SQL has deviated from the pure model when the model failed to address a real world business problems. I see SQL as a success, in that it works and applies the relational model to real world concerns. What is intuitive to users is the idea of related files/tables, and this really doesn't have much to do with the relational algebra. While we have implemented HTSQL using SQL, this is an implementation choice -- our experiment is syntax/semantics, we didn't want to be in the business of data storage and query optimization, and, we use (the incredibly awesome) PostgreSQL. HTSQL's logical query model depends upon is a tabular based abstract storage.
  - chris_wot 13y ago
    Oh, the relational query model based on relational algebra! I thought you wrote "relational model". For what it's worth, a join is indeed part of relational algebra - it's a composition of binary relations.
koolkao 13y ago
I have found SQL to be cumbersome for expressing temporal relationships, eg find all the event As that happen within one week of event B. There's not necessarily a data schema link between the table for event A and the table for event B. how does htsql do with this?
- clarkevans 13y ago
  Let's say you wish to list all students in a university, and then, show all other students with the same birth year and month. So, you'd start with ``/student`` and then you could select all columns using the asterisk. Next, you could use the ``fork()`` operation to join to the same table based on a set of columns that are correlated. /student{, /fork(year(dob),month(dob))} http://demo.htsql.org/student%7B*,%20/fork%28year%28dob%29,month%28dob%29%29%7D http://demo.htsql.org/student%7B*,%20/fork%28year%28dob%29,m... You could wrap this up in a definition to make it a bit easier to understand: /student .define(students_same_month := fork(year(dob),month(dob))) .select(, /students_same_month ) http://demo.htsql.org/student%0A.define%28students_same_month%20:=%20fork%28year%28dob%29,month%28dob%29%29%29%0A.select%28%20*,%20/students_same_month%20%29 http://demo.htsql.org/student%0A.define%28students_same_mont... With the more general case, let's say you're interested in listing per semester, which students started during that semester. In this case, you start with ``/semester`` and then define the correlated set, ``starting_students`` which uses the ``@`` attachment operator to link the two sets. Then, you'd select columns from semester and the list of correlated starting students. /semester .define(starting_students:= (student.start_date>=begin_date& student.start_date<=end_date)@student) {, /starting_students } http://demo.htsql.org/semester.define%28starting_students:=%20%28student.start_date%3E=begin_date&student.start_date%3C=end_date%29@student%29%20%7B*,%20/starting_students%20%7D http://demo.htsql.org/semester.define%28starting_students:=%... Typically, you'd include the new link definition, ``starting_students`` in your configuration file so that you don't have to define it again... then the query is quite intuitive: /semester{, /starting_students } While this all may seem complex, it's not an easy problem. More importantly, HTSQL has the notion of "navigation". You're not filtering a cross product of semesters and students, instead, you're defining a named linkage from each semester to a set of students. The rows returned in the top level of query are semesters and the rows returned in the nested level are students.

lukaseder 13y ago

I'm sure you'll agree with Stonebraker's recent (actually, not so recent) claims that the relational model is "all wrong": http://blog.jooq.org/2013/08/24/mit-prof-michael-stonebraker-the-traditional-rdbms-wisdom-is-all-wrong/ http://blog.jooq.org/2013/08/24/mit-prof-michael-stonebraker... htsql seems very interesting. I should soon blog about your product and critique. Have you been publishing elsewhere?

bcoates 13y ago
That's not complaining about the relational model at all, he's complaining about implementation details of common RDBMSes being obsolete, as they're based on row-oriented storage, slow disks, small memory, and limited concurrency. Things like Amazon Redshift are still relational but make radically different decisions on most of those points. Edit: that talk is well worth reading, btw. I wonder why he completely ignores flash though?
GFischer 13y ago
Thanks for linking to that talk, it deserves a submission all of its own.
- pkj 13y ago
  Absolutely. Very interesting talk. Definitely deserves a submission. BTW, the person asking the last couple of questions is Ed Bugnion, one of the co-founders of VMWare. He is a faculty now at EPFL.
  - lukaseder 13y ago
    Interesting, I didn't know that!
- lukaseder 13y ago
  I actually submitted it, but it didn't get too much traction...
MichaelGG 13y ago
Actually the title is "The Traditional RDBMS Wisdom is All Wrong". He's arguing against multithreaded systems in favour of a partitioned OLTP platform like H-Store (VoltDB). I didn't see anything about the relational model being "all wrong". It works well for lots of scenarios, and turning it into a KV store is also straightforward. As far as SQL, I think people agree it's not the best query language. QUEL may have won, but Stonebraker says[1]: "The only reason SQL won in the marketplace was because IBM released DB2 in 1984 without changing the System R query language." 1: http://iggyfernandez.wordpress.com/2011/12/23/nocoug-journal-interview-professor-stonebraker/ http://iggyfernandez.wordpress.com/2011/12/23/nocoug-journal...

chris_wot 13y ago

Are you criticising the relational model, or SQL? You seem to be contradicting yourself with your own language, which you claim works well with relational databases (ergo, works well with the relational model).

clarkevans 13y ago
The relational query model (it's operators and set algebra) is a poor fit for common business inquiries. I view SQL as a practical syntax for encoding relational queries; SQL has deviated from the pure model when the model failed to address a real world business problems. I see SQL as a success, in that it works and applies the relational model to real world concerns. What is intuitive to users is the idea of related files/tables, and this really doesn't have much to do with the relational algebra. While we have implemented HTSQL using SQL, this is an implementation choice -- our experiment is syntax/semantics, we didn't want to be in the business of data storage and query optimization, and, we use (the incredibly awesome) PostgreSQL. HTSQL's logical query model depends upon is a tabular based abstract storage.
- chris_wot 13y ago
  Oh, the relational query model based on relational algebra! I thought you wrote "relational model". For what it's worth, a join is indeed part of relational algebra - it's a composition of binary relations.

koolkao 13y ago

I have found SQL to be cumbersome for expressing temporal relationships, eg find all the event As that happen within one week of event B. There's not necessarily a data schema link between the table for event A and the table for event B. how does htsql do with this?

clarkevans 13y ago
Let's say you wish to list all students in a university, and then, show all other students with the same birth year and month. So, you'd start with ``/student`` and then you could select all columns using the asterisk. Next, you could use the ``fork()`` operation to join to the same table based on a set of columns that are correlated. /student{, /fork(year(dob),month(dob))} http://demo.htsql.org/student%7B*,%20/fork%28year%28dob%29,month%28dob%29%29%7D http://demo.htsql.org/student%7B*,%20/fork%28year%28dob%29,m... You could wrap this up in a definition to make it a bit easier to understand: /student .define(students_same_month := fork(year(dob),month(dob))) .select(, /students_same_month ) http://demo.htsql.org/student%0A.define%28students_same_month%20:=%20fork%28year%28dob%29,month%28dob%29%29%29%0A.select%28%20*,%20/students_same_month%20%29 http://demo.htsql.org/student%0A.define%28students_same_mont... With the more general case, let's say you're interested in listing per semester, which students started during that semester. In this case, you start with ``/semester`` and then define the correlated set, ``starting_students`` which uses the ``@`` attachment operator to link the two sets. Then, you'd select columns from semester and the list of correlated starting students. /semester .define(starting_students:= (student.start_date>=begin_date& student.start_date<=end_date)@student) {, /starting_students } http://demo.htsql.org/semester.define%28starting_students:=%20%28student.start_date%3E=begin_date&student.start_date%3C=end_date%29@student%29%20%7B*,%20/starting_students%20%7D http://demo.htsql.org/semester.define%28starting_students:=%... Typically, you'd include the new link definition, ``starting_students`` in your configuration file so that you don't have to define it again... then the query is quite intuitive: /semester{, /starting_students } While this all may seem complex, it's not an easy problem. More importantly, HTSQL has the notion of "navigation". You're not filtering a cross product of semesters and students, instead, you're defining a named linkage from each semester to a set of students. The rows returned in the top level of query are semesters and the rows returned in the nested level are students.