I love SQL, but I liked the analysis in this article. However, the EdgeQL language that was proposed looked horrible to me. It looks more like a general purpose programming language than a query language.
We Can Do Better Than SQL
321–330 of 466 posts
Re: We Can Do Better Than SQL
#322Earlier quoted context omitted.
There's no reason a diagram can't be in source control. You just need a tool that can convert the diagram to code and the code to a diagram. You probably also want to store the diagram's layout in textual form too so it can be converted back to the original human-created layout. Then you can use git and optionally build custom tools like a visual diff of diagram v1 vs v2.
The diff tool is the key here. Without that, there is no meaningful version control.
With a visual representation, diffing may be as easy as clicking next/previous between versions as you would images in an album. You could of course add more bells and whistles with highlighting.
Re: We Can Do Better Than SQL
#323Wouldn't it be easier to just propose Datalog?
Re: We Can Do Better Than SQL
#324It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…
Most relationships, I have encountered are just one-many, many-one, many-mane, one-one, indirect, direct or graphical in nature.
You want flat result, aggregated result. Why does this have to be blamed on the data relationship and not SQL language itself?
For any graphical type of relationships, I find SQL utterly hard to express my queries properly. It feels like a assembly language at that point.
Re: We Can Do Better Than SQL
#325Earlier quoted context omitted.
> SQL is messy because describing the underlying data relationships are messy. > SELECT extract(day from timestamp '2001-02-16 20:38:40'); SQL is messy because all the syntax was decided on before there was a community that really understood what good syntax is. The 'from' in that extract does nothing and I can't easily identify if extract is a function or some sort of crazy parsing construct - what are the arguments…
> It should be possible for an amateur to quickly write an SQL validator as a starting project ...why? SQL has been wildly paradigm-definingly useful for decades. It has driven hundreds of billions, perhaps trillions, of dollars of value. None of this hinges on the ability for an amateur to be able to write a validator for the language. It just seems like such a non-sequitur to me, such a strange thing to call out as…
Your last paragraph is non sequitur. It is perfectly possible for the syntax to not be the interesting part, and for SQL to have been successful despite bad syntax. The underlying idea is brilliant, so the first syntax that exposed it sufficiently well got baked in as a path dependency, even though the syntax sucks.
Re: We Can Do Better Than SQL
#326I love SQL, but I liked the analysis in this article. However, the EdgeQL language that was proposed looked horrible to me. It looks more like a general purpose programming language than a query language.
+1 for SQL.
I never understood the need to rebuild a SQL-like solution bc SQL seems like the right answer already?
Between inner joins and SPs, what else could you possibly need for data?
Re: We Can Do Better Than SQL
#327Earlier quoted context omitted.
Though I program in languages that most follow the obj.method(args) pattern, I really prefer the args |> function |> function pattern and I wish it was the norm in every programming language.
In what language is that used? It reminds me of pipes in bash. I can see it being useful in circumstances where you have lots of function calls and fewer arguments (just like pipes), but I think it would look really ugly and hard to parse with a long arg list.
See also Clojure's threading macros: https://clojure.org/guides/threading_macros
Re: We Can Do Better Than SQL
#328Speaking of SQL alternatives, Datalog seems to be another language that leverages relational model. I love how straightforward and expressive Datalog is.
I wonder, why Datalog is not very popular for databases as a query language? Is it because of performance optimization? Could anyone provide some insights?
Re: We Can Do Better Than SQL
#329Earlier quoted context omitted.
Though I program in languages that most follow the obj.method(args) pattern, I really prefer the args |> function |> function pattern and I wish it was the norm in every programming language.
In what language is that used? It reminds me of pipes in bash. I can see it being useful in circumstances where you have lots of function calls and fewer arguments (just like pipes), but I think it would look really ugly and hard to parse with a long arg list.
Julia supports it, too:
Re: We Can Do Better Than SQL
#330Earlier quoted context omitted.
>For example in Linq you can chain arbitrary many select/join/where/group by in arbitrary order. In SQL you need nested subqueries to achieve the same which is a much more convoluted syntax. WITH statements alleviate some of this issue by allowing you to write subqueries in any order.
WITH (CTEs) make queries so much more readable and digestible. As a programmer who now does data and SQL, I latched on to these as soon as I found I could reduce repetition in a query with them.
For monster queries (thousands of lines of SQL) I find that temporary tables are also great. You can index them and, depending on your DB and its settings, they're usually held in RAM so they're super fast.