Against SQL
scattered-thoughts.net
Against SQL
1–10 of 354 posts
Re: Against SQL
#2>what if we want to return the salary too?
>the only solution is to change half of the lines in the query
How about adding a second subquery for the salary.
Re: Against SQL
#3I thought they where talking about the data not being able to compress, the actual queries don't need to be compressed.
But you need to separate the data and the index so you can compress the data while still searching the index, and none of the SQL databases do that because they don't have one file per value (for obvious disk-size reasons).
We need to approach the database as files, even add features to our filesystems to accomodate that.
In my distributed HTTP/JSON database I use ext4 type small to not run out of inodes before disk space.
Re: Against SQL
#4>what if we want to return the salary too? >the only solution is to change half of the lines in the query How about adding a second subquery for the salary.
This example seemed wrong to me as well. You can have a subquery, or CTE that returns as many fields as you want and can join on the manager key
Re: Against SQL
#5This isn't just a matter of some constant programmer overhead, like SQL queries taking 20% longer to write.
20% longer to write than what alternative? And how is this being measured?
And.. am I missing something?
By far the most common case for joins is following foreign keys. SQL has no special syntax for this:
select foo.id, quux.value
from foo, bar, quux
where foo.bar_id = bar.id and bar.quux_id = quux.id
And can't some of these subqueries be written using a WHERE EXISTS or a windowing function?
Re: Against SQL
#6> So instead the best we can do is add json to the SQL spec and hope that all the databases implement it in a compatible way (they don't).
Of course they are incompatible. That's just par for the course when it comes to SQL.
Re: Against SQL
#7Lots of the examples here are yhe author writing very poor, non idiomatic SQL and then criticizing it.
I could write a point by point rebuttal but I'll just pick one point, compressibility: VIEWs.
Re: Against SQL
#8>what if we want to return the salary too? >the only solution is to change half of the lines in the query How about adding a second subquery for the salary.
It is a toy example. Perhaps imagine a more realistic subquery that is much longer. Are you going to duplicate a 50 line subquery to get the salary when all you want is one more value? No, you'd probably want to restructure the query with a join or CTE instead. To the author's point, a large change relative to the gain.
Re: Against SQL
#9Lots of the examples here are yhe author writing very poor, non idiomatic SQL and then criticizing it. I could write a point by point rebuttal but I'll just pick one point, compressibility: VIEWs.
Yeah, some of these subqueries could be fairly easily rewritten.
Re: Against SQL
#10It would be really cool if databases had an Option type. Then you could remove all the NULLs. Although you can mark a column as NOT NULL, that restriction doesn't "travel": it isn't present for function inputs/outputs, subquery results, etc. Adding it to the type system gives you a lot more mileage. And then joins could be option-aware: an inner join would have outputs matching the input types, but an outer join would have Option outputs (for at least one side).
I'm curious how much work has been done on optimizers for Tutorial D or other D variants. It looks way nicer to use, but I wonder if it is easier to stumble into pathological cases.