The path forward
https://github.com/speakeasy-engine/speakeasy/issues/26
A Short Story About SQL’s Biggest Rival
111–120 of 128 posts
Re: A Short Story About SQL’s Biggest Rival
#112I don't like either syntax. Wikipedia has this example: QUEL: range of E is EMPLOYEE retrieve into W (COMP = E.Salary / (E.Age - 18)) where E.Name = "Jones" SQL: select (e.salary / (e.age - 18)) as comp from employee as e where e.name = "Jones" I would prefer an operator syntax that directly mimics relational algebra. Something like: w = employee(name == "Jones")[comp = salary / (age - 18)] So () is "where", [] is "p…
Unbiased samples should match typography QUEL: range of e is employee retrieve into w (comp = e.salary / (e.age - 18)) where e.name = "Jones" SQL: select (E.Salary / (E.Age - 18)) as COMP from EMPLOYEE as E where E.Name = "Jones" Now QUEL looks like modern language while SQL is jarred mess.
Also `into w` is
> To store the results of the retrieve in a new table, specify `into tablename` [1].
matching SQL:
create table w as
select (e.salary / (e.age - 18)) as comp
from employee as e
where e.name = "jones"
Re: A Short Story About SQL’s Biggest Rival
#113> technically superior alternatives like Dvorak and Esperanto would have taken over. The best thing about English is the lack of accent marks. Makes each glyph unique (other than casing). Sorts are faster and not ambiguous.
It's also untrue. It's good, for some purposes, that English can be written conventionally by ignoring the accent in words such as résumé. But there are plenty of contexts, and I would say most of them, where this is going to bite you.
please provide a few real world examples.
Re: A Short Story About SQL’s Biggest Rival
#114> … The language (SQL) is not very composable. This is a fact that most SQL users are not aware of. The relational algebra that SQL is based on is absolutely composable but SQL is not due to the inherent limitation of the language (as it was designed to be natural language-like). When you write "select x from a where z", you are actually building something along the lines of "from a" => "where z" => "select x" in the…
Subqueries, named VIEWs, CTEs, etc all make SQL compostable ?
Many of the modern constructs weren’t there in 1984’s SQL, which this story describes; they were added later to address composability issues.
Re: A Short Story About SQL’s Biggest Rival
#115Had expected to read sth about Datalog, rivaling SQL at least in academic DB literature.
Apparently it is not easy to create general purpose datalog engines that scale.
"In this paper, we started with the observation that Datalog engines do not translate across domains. We experimentally evaluated the advantages and disadvantages of existing techniques, and compared them with our own baseline, a general-purpose, parallel, in-memory Datalog solver (RecStep) built upon a rdbms.
"We presented the necessary optimizations and guidelines to achieve efficiency, and demonstrated that RecStep is scalable, applicable to a range of application domains, and is competitive with highly op- timized and specialized Datalog solvers."
vldb.org/pvldb/vol12/p695-fan.pdf (2019)
Re: A Short Story About SQL’s Biggest Rival
#116Earlier quoted context omitted.
There are a handful of examples on Wikipedia: https://en.wikipedia.org/wiki/QUEL_query_languages . One example: retrieve (a=count(y.i by y.d where y.str = "ii*" or y.str = "foo"), b=max(count(y.i by y.d))) Not a particularly clear 'jumps at you' obvious semantic: * Are a and b aggregation functions or window functions? If aggregations, how do they compose if the 'by' scopes are different? * What does max(count(... by…
> The following table lists aggregate functions: > count() Number of entries in column > max() Maximum value in column > The by clause causes the function to return a set of results, as opposed to a single result. One result is returned for each grouping specified by the by clause. Think of by as meaning "for each." I assume it evaluates like retrieving set and scalar. a | b -------------- set 1 | scalar set 2 | scal…
Assuming we key a and b by y.d and generalizing b to sets, we are reaching the limits of the relational model: there is no good way to represent multiple sets associated with a given key, we need independent tables to do so. Neither cross product nor null padding is a good way to represent the schema {y, a[], b[]}.
y.d | a | b
-------------------
y0 | a0 | b0
y0 | a0 | b1
y0 | a1 | b0
y0 | a1 | b1
y0 | a2 | b0
y0 | a2 | b1
y.d | a | b
-------------------
y0 | a0 | b0
y0 | a1 | b1
y0 | a2 | nullRe: A Short Story About SQL’s Biggest Rival
#117Earlier quoted context omitted.
> The following table lists aggregate functions: > count() Number of entries in column > max() Maximum value in column > The by clause causes the function to return a set of results, as opposed to a single result. One result is returned for each grouping specified by the by clause. Think of by as meaning "for each." I assume it evaluates like retrieving set and scalar. a | b -------------- set 1 | scalar set 2 | scal…
Assuming we key a and b by y.d and generalizing b to sets, we are reaching the limits of the relational model: there is no good way to represent multiple sets associated with a given key, we need independent tables to do so. Neither cross product nor null padding is a good way to represent the schema {y, a[], b[]}. y.d | a | b ------------------- y0 | a0 | b0 y0 | a0 | b1 y0 | a1 | b0 y0 | a1 | b1 y0 | a2 | b0 y0 | a…
# create table y (i int, d int);
# insert into y values (1, 1), (1, 2), (2, 1);
# select *, (select count(*) from (select count(y.i), y.d from y group by y.d) _) as foo
from (select count(y.i), y.d from y group by y.d) _ ;
count | d | foo
-------+---+-----
1 | 2 | 2
2 | 1 | 2
(2 rows)
# with bar as (select count(y.i), y.d from y group by y.d)
select *, (select count(*) from bar) as bar from foo;Re: A Short Story About SQL’s Biggest Rival
#118Earlier quoted context omitted.
Dvorak is 25% more efficient than Qwerty using some very reasonable calculations: http://mkweb.bcgsc.ca/carpalx/?dvorak
And by some other measures (hand alternation of fingers) Dvorak is less efficient. QWERTY isn't as bad as people make it out to be, and Dvorak isn't as good as people make it out to be. There are keyboard configurations that are better than both, but nobody uses them because you'll never be able to use anybody else's keyboard.
Dvorak is that good. QWERTY is not the worst.
People always rationalize their inability to change. Those who made a step knows both rewards and cost. It was worth it hundred times.
Re: A Short Story About SQL’s Biggest Rival
#119Really the the only issue I have with SQL is NULL != NULL. This creates an impedance mismatch with most languages... MySQL sort of solves this problem with a operator, which I wish was the default for ORMs to use. There are a lot of other minor nitpicks but a lot of criticisms come down to the actual RDMS not SQL itself.
Pascal's book [1] highlights various issues with the language & is worth reading if you are not familiar with it. Example: select * from customers c inner join orders o on o.order_id = c.customer_id Legal syntax but clearly incorrect. [1] https://books.google.co.uk/books?id=t9ZQAAAAMAAJ&source=gbs_...
Do you mean “incorrect” in the sense that comparing a customer_id to an order_id is semantic nonsense?
I agree, and I do wish SQL had stronger typing so the parser could warn you before your query silently runs off the rails. For example, in Oracle, I believe the following is legal, but I wish it wasn’t:
select *
from my tab
where 1 = ‘1’Re: A Short Story About SQL’s Biggest Rival
#120can anyone find examples of what QUEL looked like? If we had a more composable query language being used instead of SQL, I wonder if that would have effected the course of ORMs, which arguably end up being as much about composable models of queries as they do about actual object mapping.
I kept searching the article, thinking I must have somehow missed the examples - nope! How very odd to wrote an article about how much better QUEL was than SQL, and not have a single example of either!