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?
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?
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...
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.
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.
For what it's worth, a join is indeed part of relational algebra - it's a composition of binary relations.
how does htsql do with this?
/student{, /fork(year(dob),month(dob))}
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_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:=%...
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.
I made some queries that are analogous to my temporal query needs
Here I'm looking for every student, other students with DOB within 2 weeks of the given student: http://demo.htsql.org/student.define(similar_students:=%20(s...
Here for every semester with at least one student, I find the oldest and the youngest students enrolled: http://demo.htsql.org/semester%20.define(starting_students:=...
No being a computer scientist I have to admit I do not appreciate the intricacies of the 'problems with SQL' blog entries. But working with htsql I gotta say it seems a lot more intuitive than SQL. It feels like the logic correspond much better to my mental model. And that there is much less of the jumping up and down the code to nest my SQL code logic that I find myself doing all the time.
Is there a way to install this on a PostgresQL instance on Win8?
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
Our critique of SQL is at http://htsql.org/doc/overview.html#why-not-sql