Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Relational is more than SQL

fauna.com

Post reply on HN
Print view View original

101–110 of 177 posts

Re: Relational is more than SQL

#101

Post by lolinder »

remram wrote: post #70
ttfkam wrote: post #68

Earlier quoted context omitted.

The syntax comparison section will likely sour a lot of viewers who already know SQL. You try too hard to highlight how easy and terse PRQL is by putting comma-separated items on their own lines but in SQL you put each item on separate lines. It may be typical of many SQL users and formatters, but it leaves a poor taste in the mouth that you aren't interested in an actual comparison but in marketing. For those who al…

It's just syntax, it compiles to SQL and runs on today's DBMS. It has no difference in speed or functionality.

It does make a difference if the resulting SQL is unperformant.

Someone who is good at SQL can look at a query and see where the query planner might go wrong, then make subtle tweaks to get better performance. Optimizing queries in a compile-to-SQL language basically has to be left to the compiler, which may not have the context needed to write performant SQL.

Compiling a query is different than compiling a whole program to assembly, because the query makes assumptions about schemas and indexes that cannot be encapsulated in what you're feeding to the compiler at that moment.

Re: Relational is more than SQL

#102

Post by Izkata »

ttfkam wrote: post #68
snthpy wrote: post #12

Disclaimer: I'm a core contributor to PRQL [1] and post about it a lot on HN. Apologies for jumping in on other people's threads, but for people interested in the headline, PRQL might be of interest. At PRQL[1] we believe that SQL is a combination of two things: 1. Relational Algebra, which is eternal because it's just maths, and 2. A language designed in the 70s that looks like COBOL. When people say that SQL will n…

The syntax comparison section will likely sour a lot of viewers who already know SQL. You try too hard to highlight how easy and terse PRQL is by putting comma-separated items on their own lines but in SQL you put each item on separate lines. It may be typical of many SQL users and formatters, but it leaves a poor taste in the mouth that you aren't interested in an actual comparison but in marketing. For those who al…

> Putting the FROM first isn't sufficiently compelling on its own.

Personally I see that as not even neutral, it's a downside. Optimizing for autocomplete is an antipattern, code is read far more often that it's written and the SELECT clause is the interface to the following code. It should be easy to find when skimming, not buried in the query.

The SELECT clause is also akin to an assignment and it's extremely rare I see anyone advocating flipping the order of those to match what they say they want in SQL.

Edit: Since I'm sure someone is going to jump on it, yes, I'm conflicted about the WITH clause: It's extremely useful and I like what it does, so I do use it, but I don't like where it's positioned. I've been toying with indentation to work around it so SELECT is still just as visible as otherwise.

Re: Relational is more than SQL

#103

Post by Izkata »

smaddox wrote: post #74
danielvaughn wrote: post #46

Earlier quoted context omitted.

Yeah I’m a web dev, and recently I found out the most popular JS ORM doesn’t produce joins. It’ll just execute multiple queries in sequence. I don’t know how common that is in the ORM landscape but for me that’s a deal breaker.

Common enough to have a name: the N+1 query problem.

1+N is clearer I think, and what I remember seeing in the past - it matches what's actually happening with this problem. First time I saw N+1 sometime around a year ago, I had no idea it referred to the same thing and thought it was something different.

N+1 looks like an issue with aggregation after a parallel run, something I've encountered with celery tasks before.

Re: Relational is more than SQL

#104

Post by ako »

default-kramer wrote: post #81
ako wrote: post #4

Seems like a lot of what fauna does by storing documents isn’t really new, oracle, Postgres and others have provided this for a long time. I was really surprised by the performance of json queries [1], opens the doors to using Postgres as a client api cache, storing the payload in a table, and doing deserialization using (materialized) views. Difference seems to be the approach to minimize number of calls from your a…

Using FQL instead of SQL seems to be a pretty big difference too.

Postgres has procedural languages and enables you to return complex json structures combined of relational data and json documents both with its procedural languages and regular sql. Sure, the syntax is different, but not sure if the difference makes a big impact.

Re: Relational is more than SQL

#105

Post by totalhack »

bob1029 wrote: post #91
slotrans wrote: post #86

Fixed schemas are good. Document stores are bad. SQL is good. Stop doing this nonsense. It's a step backwards. As the intro points out, hierarchical and graph DBs came first , and relational was built in part to solve their problems. Document DBs just bring those problems back.

> Fixed schemas are good. I recall getting into an argument recently (perhaps on HN) wherein the central thesis for why SQL is bad is because the schema is "difficult" to change relative to a document store or other no-SQL abstraction. If you don't have a clear idea of what the representative SQL schema might be for your problem or business (say, within ~80%+ certainty), one may argue you should not be writing any so…

There are also ways to add some flexibility into a "fixed" schema when you need it. Entity-attribute-value tables, views, JSON columns (as a last resort), or a semantic layer like https://github.com/totalhack/zillion

Re: Relational is more than SQL

#106

Post by Scarbutt »

lolinder wrote: post #98
snthpy wrote: post #12

Disclaimer: I'm a core contributor to PRQL [1] and post about it a lot on HN. Apologies for jumping in on other people's threads, but for people interested in the headline, PRQL might be of interest. At PRQL[1] we believe that SQL is a combination of two things: 1. Relational Algebra, which is eternal because it's just maths, and 2. A language designed in the 70s that looks like COBOL. When people say that SQL will n…

SQL will never die for the same reason that JavaScript will never die: because it's built in to all major database engines. In both cases, any other language will be starting as a second class citizen that has to compile to SQL/JS. During this phase of a new language's lifetime, it is either a surface-level syntactic change (a la Coffeescript) that provides no objective improvement, or it has to compile its simple se…

It's hard to say, if microsoft or google where behind prql and promoting it, it may as well become a typescript. There's a reason many developers use query builders, while not exactly the same, they want programming language features and familiarity of modern programming languages. Not saying prql is the correct approach here since I don't know it.

Re: Relational is more than SQL

#107

Post by Zak »

lolinder wrote: post #100
paulddraper wrote: post #99

Earlier quoted context omitted.

While I mostly agree, there is a bit of Stockholms syndrome. A lot of people don't know what they even could be missing. For example, there is no succinct way of writing an antijoin in SQL . The MERGE command has only been implemented by some engines due to (IIRC) concurrency concerns/ambiguities. ANSI SQL JSON operations have improved but are still clunky. Boolean NULL and IN is a clusterf of footguns. Etc.

Oh, I agree! SQL is far from optimal, as is JS. My thoughts are more about the feasibility of a replacement than the need for one. US electrical outlets are also highly flawed, but we're never going to replace them either. Standards, once entrenched, are nearly impossible to uproot.

I like US electrical outlets. They make for small, foldable plugs.

Yes, it's easier to shock one's self than with most other outlet designs, but the consequences of that are usually mild and help to instill a healthy respect for electricity.

Re: Relational is more than SQL

#108

Post by Scarbutt »

wackget wrote: post #87
ttfkam wrote: post #68

Earlier quoted context omitted.

The syntax comparison section will likely sour a lot of viewers who already know SQL. You try too hard to highlight how easy and terse PRQL is by putting comma-separated items on their own lines but in SQL you put each item on separate lines. It may be typical of many SQL users and formatters, but it leaves a poor taste in the mouth that you aren't interested in an actual comparison but in marketing. For those who al…

Yeah the syntax comparison is deliberately misleading. They style it as "4 lines vs 10 lines!" when it's actually 4 lines vs 4 lines. # PRQL from employees select {id, first_name, age} sort age take 10 # Misleading SQL SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 # Actual SQL SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 The join example is similarly deceptive: # PRQL from employe…

Looks like they are showcasing the output of the compiler, not the hand written SQL.

Re: Relational is more than SQL

#109

Post by roenxi »

snthpy wrote: post #55
roenxi wrote: post #44

Earlier quoted context omitted.

Great project, wish you all the best. Anything to try and unseat SQL from common use (we can all wish for the day we run PostgrespostSQL in production). At the moment the project is probably going to lose people because it isn't obvious how to get started - many SQL beginners don't know what a compiler is and will get confused by the docs. For the sake of their sanity, it'd be worth considering putting an example of…

Thank you for your feedback. That's really valuable! We have the [PRQL Playground]( https://prql-lang.org/playground/ ) exactly for that purpose. We'll try and make it more prominent on the front page. I've also felt that we should have a "Getting started" page and will push that as a priority.

Ah, I see. Maybe you're just losing beginners who NoScript then. I hadn't figured out what the Playground was supposed to do but it turned out there was an extra disabled script.

Nevermind, thanks.

Re: Relational is more than SQL

#110

Post by bob1029 »

totalhack wrote: post #105
bob1029 wrote: post #91

Earlier quoted context omitted.

> Fixed schemas are good. I recall getting into an argument recently (perhaps on HN) wherein the central thesis for why SQL is bad is because the schema is "difficult" to change relative to a document store or other no-SQL abstraction. If you don't have a clear idea of what the representative SQL schema might be for your problem or business (say, within ~80%+ certainty), one may argue you should not be writing any so…

There are also ways to add some flexibility into a "fixed" schema when you need it. Entity-attribute-value tables, views, JSON columns (as a last resort), or a semantic layer like https://github.com/totalhack/zillion

> JSON columns (as a last resort)

This is the design-time escape hatch for me. The remaining 20% space of unknowns can usually be dealt with here. As long as the most critical tables, relations & properties have been set in stone, I would find it reasonable to allow a "ExtendedPropertiesJson" column in limited areas of the schema.

Over time, these JSON blobs should be refactored into the schema as features become more stable.

The key is to have a solid relational model as the foundation. You cannot really do it the other way around.

Post reply on HN