> In a real coup we hired a superb team from Xerox PARC.
Once again, California's absence of noncompetes plays a critical role in the success of a business.
A Short Story About SQL’s Biggest Rival
71–80 of 128 posts
Re: A Short Story About SQL’s Biggest Rival
#72Really 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.
My bigger concern regarding NULLs is that its a ternary logic shoved into a binary logic system, and it all invisibly becomes nonsense when your dataset has NULLs in it, and you don't explicitly address it WHERE col1 > col2 is wrong, and it'll break in terrible ways and in the face of negation + NULLs, everything falls apart[0], giving you both false positive and false negatives in your answerset, and everything will…
This is basically the correct take, but I would say that NULL is a real and useful concept which databases should have.
That implies that comparison and boolean operators should be ternary, which would be ugly and confusing: but an ugly and confusing that reflects reality.
This would give us three "greater than" operators:
WHERE col1 > col2
WHERE col1 ?> col2
WHERE col1 >? col2
The most important of such operators would be
WHERE col1 ?= col2
Re: A Short Story About SQL’s Biggest Rival
#73Really 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.
The SQL standard also defined an operator for that: IS DISTINCT FROM
Re: A Short Story About SQL’s Biggest Rival
#74> 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.
Re: A Short Story About SQL’s Biggest Rival
#75I'd been aware of Codd's relational theory, but never heard of QUEL – now I want to find a database engine that implements QUEL!
As far as I'm aware only Ingres supports QUEL Edit: In case you actually do want to play with it, Ingres is now Actian IngresX. Though I'd recommend thinking about what could have been instead of actually spending any time fighting with and configuring Ingres.
Uh, it's nice to see the name Actian come out for once.
My previous employer used Versant by Actian (now called Actian NoSQL) heavily.
It's much more of a NoSQL database: it's a real object oriented database. You don't store tuples, you store objects. You don't make queries with selection and projection, you make a cut of a graph of objects.
It's insanely fast, multithreaded, has very good tooling, scales vertically very well, can do online schema evolution (class definition evolution, really).
Sadly it's almost impossible to scale horizontally (I'd be glad to be proven wrong).
It's basically what the industry needs to avoid the object-relational mismatch: an object oriented database.
But everybody only learns SQL...
Re: A Short Story About SQL’s Biggest Rival
#76Earlier quoted context omitted.
Those are not mutually exclusive. (One could add "foolish" and "short-sighted" to the list of potentially compatible adjectives.)
And RMS being a good example of a principled and arrogant man that was neither foolish nor short sighted.
The more we go forward with technology and everything, the more I understand: Stallman was 110% damn right the whole time, and was lightyears ahead in seeing what other people couldn't see.
Proprietary software is a cancer.
Re: A Short Story About SQL’s Biggest Rival
#77I 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…
I would reorder round and square brackets, since I may want to filter on computed/created columns, and the ordering makes it clearer.
Re: A Short Story About SQL’s Biggest Rival
#78I 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…
I would reorder round and square brackets, since I may want to filter on computed/created columns, and the ordering makes it clearer.
It's up to you (and the query optimizer can reorder), but you have to make sure the column is available when you use it. Broken up:
I had:
a = employee(name == "Jones") a has name, salary and age
w = a[comp = salary / (age - 18)] w has comp
b = employee[name, comp = salary / (age - 18)] b has name and comp
w = b(name == "Jones" && comp > 500) w has name and comp
w = employee[name, comp = salary / (age - 18)](name == "Jones" && comp > 500)Re: A Short Story About SQL’s Biggest Rival
#79Had expected to read sth about Datalog, rivaling SQL at least in academic DB literature.
Re: A Short Story About SQL’s Biggest Rival
#80I 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…
They should implement something using straight functions, extremely spartan with no special syntax at all, and let everyone build their own favoured DSL over the top.
One of my major complaints about SQL is the syntax is so finicky that it is really hard to replace it with a [something -> sql] layer, because the something layer can't generate all the silly syntactic forms that SQL uses.
Eg, personal favourite, it is easy to have a dsl that translates
select(y = fn(x)) -> select fn(x) as y
??? -> select extract(month from x) as y