Of all the SQL flavors/derivatives, I like PRQL the most: https://prql-lang.org/
Previous HN discussion from a month ago: https://news.ycombinator.com/item?id=36866861
Beyond SQL: A relational database for modern applications
31–40 of 61 posts
Re: Beyond SQL: A relational database for modern applications
#32> SQL query performance is opaque and dependent on an optimizer to make the right decision. The developer has imprecise control and a given query pattern's plan of execution is subject to change at unpredictable times.
This is really hilarious framing to me.
The entire point is to make the whole process opaque to the developer (unless they insist upon explaining a query plan). SQL is about maximizing productivity and focusing on the information of the business. Being able to write a SELECT statement that has never been seen by any other computer on earth and have it execute ideally 95%+ of the time is pretty close to pure magic.
Why would you reset 20+ years worth of experience on an existing SQL query planner/optimizer/et. al.? Wouldn't you rather build & ship a working product?
Re: Beyond SQL: A relational database for modern applications
#33I buy the need for something like FQL. But I don’t buy that this should be connected to a proprietary service. Or that the alternative query language should be a proprietary language. For something long-term or critical, it seems like a pretty large business risk. We don’t have to use any imagination to see how this plays out — look at Oracle. Though it could be worse — imagine you build a successful business on it a…
One could implement a FQL -> SQL compiler and then it could be used anywhere.
The ability though to safely encode logic in SQL in a single round trip would be really nice. FQL could be a better way of doing "ORM". Although you can find similar tools for SQL that help map joined results into arrays, etc, but don't obscure the SQL (for example Jet for Golang).
Re: Beyond SQL: A relational database for modern applications
#34> SQL query performance is opaque and dependent on an optimizer to make the right decision. The developer has imprecise control and a given query pattern's plan of execution is subject to change at unpredictable times. This is really hilarious framing to me. The entire point is to make the whole process opaque to the developer (unless they insist upon explaining a query plan). SQL is about maximizing productivity and…
Sql is one of the coolest languages ever developed and I hate the resistance to it. It's basically applying relations over (multi)sets, and set theory can be at the root of basically all today's mathematics if you squint or translate hard enough. So much of programming is taking data from one place and putting it in another, having a consistent language to do so such as ANSI sql is so powerful.
Until cloud formation/terraform/infrastructure as code came around it was basically the only declarative language that most developers would come across (unless you count markup), and I think that was the cause of some of the resistance.
Re: Beyond SQL: A relational database for modern applications
#35is it pronounced fackle? fuckle? fickle? feeckle?
Fecal. Like Sequal.
Re: Beyond SQL: A relational database for modern applications
#36People re-inventing SQL reminds me of the same people that keep trying to re-write standard Staff Music Notation.
Yeah, it's not perfect, but the suggested replacements are marginal gains, if anything.
In order to replace SQL, you probably need something like a 10x improvement, so it sells like hotcakes. Nothing about those examples screams that sort of improvement.
I mean, cool they put some stuff on the left instead of the right. And I guess the select clause is in a little better order now. Yay.
Re: Beyond SQL: A relational database for modern applications
#37Isn't there one of these every 6 months on here? Dread it, run from it, SQL arrives all the same
I disagree. This is a hard problem that take time to solve. I hope the world do not stop SQL.
Re: Beyond SQL: A relational database for modern applications
#38People re-inventing SQL reminds me of the same people that keep trying to re-write standard Staff Music Notation. Yeah, it's not perfect, but the suggested replacements are marginal gains, if anything. In order to replace SQL, you probably need something like a 10x improvement, so it sells like hotcakes. Nothing about those examples screams that sort of improvement. I mean, cool they put some stuff on the left instea…
I agree with what you say.
On the other hand, it shows how when something gets popular enough it gets stuck in place, unable to progress slowly towards better, because we keep calling it good enough and all marginal improvements that accumulate to something significant over time are rejected.
And this friction can be a significant problem, because it can cause systems to die overtime by being suddenly replaced, disrupted, from below by something that is a major improvement but completely incompatible with the status quo. Think of it as having a devastating earthquake after a long period of complete calm.
This is not good for anyone, we will be much better served by small gradual improvements to existing systems. This is how we came to be ourselves through evolution.
Re: Beyond SQL: A relational database for modern applications
#39Good luck though, you're going up against giants (as much as this article portrays SQL as outdated, anyone who tries to go against it is very much the underdog). It's hard to get people to buy in on a custom database stack that is made by only a single company. And the fact that this article reads like a one sided praise for Fauna doesn't inspire confidence either, I want to read some real negatives from people who have used the thing.
Re: Beyond SQL: A relational database for modern applications
#40One of my side ideas is to write a postgres plugin offering an alternative syntax for queries, but one that requires you to name the index you use (or to explicitly mention a table scan). I do understand the value of SQL + the planner for adhoc querying. But so many times I find myself reworking SQL to hint at the planner to use certain indexes, or to add "spurious" filters to make sure an index is used (spurious for…
MySQL has a "use index" hint. https://dev.mysql.com/doc/refman/8.0/en/index-hints.html
I may have used it at most once. But I'm not mr big data over here.