3 ms·
As for myself, I wish SQL's SELECT were more expressive. It's currently organized almost exactly like a mirror of the underlying relational algebra operators th
by atombender 8y ago
As for myself, I wish SQL's SELECT were more expressive. It's currently organized almost exactly like a mirror of the underlying relational algebra operators that a query engine has to execute internally.
But relational operators isn't what developers like to work with. SQL is about "projecting" relations, putting them through some basic transforms, none of which compose that well because of SQL's statement-oriented syntax. For example, you can't group a group-by. A group-by takes a list of terms, but you can't funnel the output through another one without wrapping the whole query in a "SELECT FROM (...) AS ...".
I'd like a query language that more expressive, expression-based syntax where the results of each expression can be "piped" into the next step to perform transformations, joins, reductions and so on.
- ah- 8y agokdbs q-sql does improve a lot on that. Especially expressiveness. https://code.kx.com/q/ref/qsql/ https://code.kx.com/q/ref/qsql/ http://www.timestored.com/b/kdb-qsql-query-vs-sql/ http://www.timestored.com/b/kdb-qsql-query-vs-sql/
- olavk 8y agoYeah, this is my main beef with SQL. The syntax is just clunky when you want to compose operations. Linq does this much better. With-clauses (aka Common Table Expressions) improves this a lot, but it would be better still if you could just write: FROM <table> WHERE <filter> SELECT <projection> GROUP BY <groupings> WHERE <filter> SELECT <projection> and so on.
- MarkusWinand 8y agoSQL uses nesting as you have shown instead of a "pipe" (think of it like functional programming). The difference is just the syntax, not the expressiveness.
- atombender 8y agoWell, I am explicitly talking about syntax.
- ccleve 8y agoI often use temporary tables to hold intermediate results. Does that not work for you?
- asavinov 8y ago> I'd like a query language that more expressive, expression-based syntax where the results of each expression can be "piped" into the next step to perform transformations, joins, reductions and so on. I do not think this can be easily fixed in SQL because the problems are not in the syntax but rather lie deeper at the level of the underlying paradigm and principles.