[sschnei8]

What is the human need to bash SQL at all costs? At its core, such a simple syntax, yet its so powerful at aggregating/manipulating tabular data and the like. Instead we’d rather declaratively say what we want in a more verbose/disjointed way… fascinating

[nonethewiser]

I'm with you. The more SQL alternatives I've seen, the more I'm convinced that SQL doesn't have that much fat or disfunction in it's syntax. There is inherent complexity. Follow an SQL-killer's guide far enough and you will see them quietly reintroduce the very same abstractions SQL solved decades ago.

[CodesInChaos]

For me SQL feels like PHP. Sure it's usable, but it doesn't spark joy.

Syntactically PRQL is much simpler, cleaner and more flexible. You simply chain pipeline stages instead of having a single monolithic query statement.

Data model wise EdgeQL is close to what I want (links instead of joins, optionality instead of null, nesting support), but it's syntax is almost as bad as SQL.

[unshavedyak]

Oh man, PRQL looks so good.

I just wish they had mutation in there too. I don't like the idea of swapping between PRQL and SQL, let alone some complex update statements where i'd rather write the query in PRQL. .. Yea you could argue they shouldn't be that complex for updates though heh.

[snthpy]

Yeah, we deliberately left out DML to focus on DQL exclusively. I also find that appealing from a philosophical angle since it allows PRQL to remain completely functional.

I haven't thought about DML too much but what I could envision is an approach like the Elm or React architecture where you specify a new state for a table as a PRQL query and then the compiler computes the diff and issues an efficient update.

For example

    DELETE FROM table_name WHERE id = 1;

would be something like

    table_name = from table_name | filter id != 1

SQL:

    INSERT INTO table_name (id, name) VALUES (1, 'Jane');

PRQL:

   table_name = from table_name | append [{id=1, name='Jane'}]

Update is the trickiest to not have clunky syntax. For example what should the following look like?

SQL:

    UPDATE table_name SET name = 'John' WHERE id = 1;

I can think of `filter` followed by `append` or maybe a case statement but neither seems great.

Any ideas?

[reverseindex]

I used to use SQL very extensively, but then I moved into different roles, and now I always have to look up its syntax, stuff like "how did HAVING work again?", "how do I search for a date two days before today". With Text-to-SQL I can express my query in natural language. Because I have a very solid understanding of relational data models I can craft my prompt very precisely, but without constantly having to go back to the documentation. So at least for casual users it's very helpful.

[dvdkon]

I'll give one reason of many: Its fixed pipeline model doesn't match how humans think about data transformation.

[johtso]

When you're having to work with someone else's godawful convoluted database schema you're sometimes really happy not to have to write the query yourself. Giving the LLM context with previously written queries can be quite effective.

The writing SQL experience is a product of both SQL's syntax, the structure of the database you're querying over and the complexity of your query.

When things get hairy, and you have a good number of representative queries already written that you can use as context, LLMs can be really nice tool.

[sschnei8]

Agreed, but maybe the step change there is refactoring the data model, not continuing to author “hairy” sql via LLM that’s all fine until it breaks… and you end having to mend the nastiness back into compliance the ol’ fashion way

[fijiaarone]

You could definitely load your billions of records with millions of relationships into memory, denormalize, restructure and rewrite the data (flawlessly) a lot cheaper (computationally) than running a large LLM on all that hardware.