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

161–170 of 177 posts

Re: Relational is more than SQL

#161

Post by Zak »

iamsam123 wrote: post #84
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…

Does it SELECT * by default if I never define a SELECT below my FROM? ... Continuing to encourage folks by allowing them to SELECT * easier is would not be fun for me... I could be wrong? Agreed, just parsing out the formatting so its "fewer lines" than traditional SQL soured me. The expressions example is ridiculous, in Redshift I can do this all day?? SELECT 1 + 2 AS num1 , num1 * 2 AS num2 -- Literally no differen…

> Just learn SQL...

I know SQL, and I imagine the authors of PRQL know it better than I do.

Doesn't it seem weird that dozens of application languages have become popular since the 1970s, but we're still using dialects of the same old database query language? If it had a really elegant syntax, perhaps it wouldn't, but SQL's syntax is anything but. Some of the semantics can be awkward as well.

I, for one welcome attempts to move things forward (which is different from saying I'm going to run out and use PRQL in production tomorrow).

Re: Relational is more than SQL

#162

Post by ttfkam »

naasking wrote: post #159
ttfkam wrote: post #155

Earlier quoted context omitted.

When viewed as a DSL for set theory, views, CTEs, set-returning functions, et al are indeed proper first-class query abstractions. When viewed through the lens of general purpose imperative or functional programming languages, it's easy to see how it can be seen as falling short. I'll admit much of the tooling and driver APIs leave a lot to be desired. Some tools do make good efforts though such as nested fragments i…

> When viewed as a DSL for set theory, views, CTEs, set-returning functions, et al are indeed proper first-class query abstractions. It's still lacking even then. You can't assign a set to variable for instance, and then use that variable in other definitions or queries.

You can in Postgres. It's not often a good idea since it would constitute an optimization fence and potentially buffer large values in memory, but you can absolutely do this in a function variable.

    record[]
    some_table_name[]
    jsonb containing an array of records
And of course the most obvious shared set variable of all, supported by every popular RDBMS in existence: the temporary table. Something scoped to the current session, of essentially unlimited width and length, and accessible to other definitions and queries.

We get it. You want something closer to a general purpose programming language. But don't confuse your preferences with actual missing features.

Re: Relational is more than SQL

#163

Post by ttfkam »

maximilianroos wrote: post #157
ttfkam wrote: post #152

Earlier quoted context omitted.

Agreed. Got off on the wrong foot. I and others have noted what appeared to be overzealous marketing, and I previously asked questions regarding DB engine-specific features like jsonpath, unnest for arrays, etc. The responses from the PQRL appeared evasive to me, asking for PRs to address obvious syntax mismatches, and never answering (what I believed to be) substantive questions regarding extensibility and lowest co…

I appreciate the lengthy response. I won't address every point here, but a couple of thoughts: - To close the syntax point — I opened https://github.com/PRQL/prql/issues/3518 . We're currently using the output of the rust's canonical SQL formatter. (so any claim we're obfuscating SQL's syntax is incredulous — do you agree?). I'm open to hand-written examples if SQL doesn't have sufficient auto-formatting tools availa…

> For context, PRQL's Readme specifically states

Be honest. If a different project touted itself as a standard and a firm foundation on its public website but had this disclaimer on the source repo's README file, what would your thoughts be?

While you may categorize my responses as reactionary—and they very well may be—can you really claim unbiased objectivity on your part?

For example, JS and C# have ECMA. SQL, C, and C++ have ISO. POSIX has IEEE. All have multiple implementations by different organizations. The term "standard" has a clear, well-defined meaning in computing with a long history. Your response was to handwave it away as "meaning multiple things." Whether de facto or de jure, the appellation in PRQL's case simply does not apply.

I appreciate that you are not obligated to read and respond to every internet comment. When you do respond however, bear in mind that dismissing clearly defined definitions of industry terms like "stable" and "standard" is not an unbiased position.

I am not aggrieved. You asked for critical and constructive feedback. I laid out plainly where I believed the messaging was incongruous from the point of view of someone not intimately involved with PRQL and how I felt it should be changed to better fit its role in the data ecosystem. I didn't call for the project's elimination or even call into question the need for improvement over the existing state of SQL. Take of that what you will.

Re: Relational is more than SQL

#164

Post by austhrow743 »

probablypower wrote: post #75
herodoturtle wrote: post #3

This is a very interesting way to promote a product, credit to the author (who is an industry veteran it seems). I had no idea what Fauna was. I just clicked the link here because the title caught my eye (I work with databases quite a bit). The opening paragraph immediately grabbed my attention - "My first deep dive into SQL was in 1987, just before I became the first technical person at Microsoft to work on SQL Serv…

This is interesting, because I have the exact opposite response to these sorts of articles. I think any bias or personal interest should be declared upfront in media (articles, videos, podcasts, ...) rather than appear as a 'common consumer' talking about a pain point in a relatable way. It really rubs me the wrong way when an article ends with a bait-and-switch, where you realise the entire article was manufactured…

Why would your original assumption not be that the Fauna website exists to promote Fauna?

Re: Relational is more than SQL

#165

Post by naasking »

ttfkam wrote: post #162
naasking wrote: post #159

Earlier quoted context omitted.

> When viewed as a DSL for set theory, views, CTEs, set-returning functions, et al are indeed proper first-class query abstractions. It's still lacking even then. You can't assign a set to variable for instance, and then use that variable in other definitions or queries.

You can in Postgres. It's not often a good idea since it would constitute an optimization fence and potentially buffer large values in memory, but you can absolutely do this in a function variable. record[] some_table_name[] jsonb containing an array of records And of course the most obvious shared set variable of all, supported by every popular RDBMS in existence: the temporary table. Something scoped to the current…

Temp tables are another bandaid. Like views, they are another second-class abstraction intended to address the lack of generality of relations. As you hint, adding second-class features is intended to handle pain points while keeping optimization simple, but it's the wrong way to do it IMO. No fixed number of second class features can make up for the lack of relations as first-class values, so this is not just a matter of preference.

I actually don't want a general purpose programming language as that's not suitable for data access, I just want a query language that doesn't impose artificial limitations on relations.

Edit: although I will admit that programming language theory is a hobby, so that's why I understand the source of the pain every time I have to use SQL. LINQ almost gets this right, but is still a huge improvement on SQL.

Re: Relational is more than SQL

#166

Post by lcnPylGDnU4H9OF »

pphysch wrote: post #95
lcnPylGDnU4H9OF wrote: post #88

Earlier quoted context omitted.

At this point, one chooses the solution for their problem. The reason the fads occur is that a person who vaguely understands both the problem and the solution will write a blog post which happens to go viral talking about how the solution will solve all problems. NoSQL databases aren’t unilaterally worse than relational ones. They just solve different problems.

> NoSQL databases aren’t unilaterally worse than relational ones. They just solve different problems. I can't prove this, but I assert that a relational database that has solid JSON+text support (e.g. Postgres) is on much better footing than a NoSQL DB that attempts to implement a true relational model. One is a adding a special new datatype, the other is trying to add an entire paradigm. Just use Postgres. If you do…

> a relational database that has solid JSON+text support (e.g. Postgres) [vs] a NoSQL DB that attempts to implement a true relational model

I think both cases are similar to using a flat-head screwdriver for a phillips screw. It will technically work but you might run into otherwise avoidable problems. Use the right tool for the job. Though generally a relational database with JSON support will better serve most web applications, a nosql db might better serve niche internal processing.

Re: Relational is more than SQL

#167

Post by chrisjc »

maximilianroos wrote: post #120
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…

[PRQL dev here] I strongly think we should have the best examples of SQL to compare against. I've ironically made this complaint for other libraries, so I'm alarmed that folks think we might have done the same. We would take PRs for any improvements to the SQL that make it a better comparison.

Not a criticism, more of an observation.

The point of being able to write "FROM" before "SELECT" has become moot to me since many DBs support that SQL "convention" already.

The newline/indentation is something I would do for readability in the PRQL too.

At the end of the day, I'm becoming less concerned about these various query language syntaxes and more concerned about the logical and physical plans generated by the respective query engines.

In my experience, what ends up most problematic is that each query-engine/optimizer sometimes/usually requires SQL tweaks/nuances to perform as efficiently as possible. That's where reading/writing/maintaining queries can get really confusing/difficult. An abstraction such as PRQL, dataframes, etc might add value here, but only if the abstraction (or runtime/evn built around it) can tune the output SQL to each query engine as it is needed.

There are a lot of projects using frameworks/libraries such as Substrait and SQLGlot to accomplish this.

https://substrait.io/

https://github.com/tobymao/sqlglot

Re: Relational is more than SQL

#168

Post by chrisjc »

maximilianroos wrote: post #117
lolinder wrote: post #98

Earlier quoted context omitted.

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…

[PRQL dev here] I agree with the sentiments, even if not the conclusion. SQL is omnipresent and is "fine" in a lot of cases. TypeScript is indeed a great example of the case; Kotlin too. I'd also add that databases are already adding PRQL support — ClickHouse has native support, there's a DuckDB extension, and folks are working on a Postgres extension. One thing I'll respectfully disagree with — "SQL is highly static…

> One thing I'll respectfully disagree with — "SQL is highly statically analyzable by nature"

Are you suggesting that PRQL is capable of this? Or at least easier to do in PRQL?

Re: Relational is more than SQL

#169

Post by ttfkam »

naasking wrote: post #165
ttfkam wrote: post #162

Earlier quoted context omitted.

You can in Postgres. It's not often a good idea since it would constitute an optimization fence and potentially buffer large values in memory, but you can absolutely do this in a function variable. record[] some_table_name[] jsonb containing an array of records And of course the most obvious shared set variable of all, supported by every popular RDBMS in existence: the temporary table. Something scoped to the current…

Temp tables are another bandaid. Like views, they are another second-class abstraction intended to address the lack of generality of relations. As you hint, adding second-class features is intended to handle pain points while keeping optimization simple, but it's the wrong way to do it IMO. No fixed number of second class features can make up for the lack of relations as first-class values, so this is not just a matt…

How would LINQ make jsonpath queries or unroll arrays on the database with unnest?

Re: Relational is more than SQL

#170

Post by ttfkam »

Zak wrote: post #161
iamsam123 wrote: post #84

Earlier quoted context omitted.

Does it SELECT * by default if I never define a SELECT below my FROM? ... Continuing to encourage folks by allowing them to SELECT * easier is would not be fun for me... I could be wrong? Agreed, just parsing out the formatting so its "fewer lines" than traditional SQL soured me. The expressions example is ridiculous, in Redshift I can do this all day?? SELECT 1 + 2 AS num1 , num1 * 2 AS num2 -- Literally no differen…

> Just learn SQL... I know SQL, and I imagine the authors of PRQL know it better than I do. Doesn't it seem weird that dozens of application languages have become popular since the 1970s, but we're still using dialects of the same old database query language? If it had a really elegant syntax, perhaps it wouldn't, but SQL's syntax is anything but. Some of the semantics can be awkward as well. I, for one welcome attem…

> Doesn't it seem weird that dozens of application languages have become popular since the 1970s, but we're still using dialects of the same old database query language?

Indeed. Do you honestly believe that a half-century of data storage professionals and vendors are blindly moving forward with a hobbled tool?

Or maybe there are aspects of SQL as a set-oriented 4th generation programming language that aren't apparent to folks who are intimately tied to an imperative or functional programming paradigm as opposed to a declarative DSL for set theory.

Post reply on HN