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

The Rise of SQL:the second programming language everyone needs to know

spectrum.ieee.org

Post reply on HN
Print view View original

121–130 of 139 posts

Re: The Rise of SQL:the second programming language everyone needs to know

#121

Post by geysersam »

hunterpayne wrote: post #77
randomNumber7 wrote: post #44

Earlier quoted context omitted.

Also SQL is not turing complete. I see it more as a descriptive language like e.g. html is a language but not a programming language.

This is completely wrong. The SQL spec isn't Turning complete but multiple DBs provide Turing complete extensions (like pgplsql) that make it so. Also, even without the extensions, it is still very much a programming language by any definition of the term. Like most takes on SQL, it is more about your understanding (or lack thereof) of SQL.

I was under the impression that recursive CTEs make the SQL spec Turing complete. Not that it makes any practical difference, it's still very difficult to use for "general purpose" programming, and still very practical to use for data processing / management.

Last year I read about some database researcher who implemented AoC in pretty standard SQL.

Re: The Rise of SQL:the second programming language everyone needs to know

#122

Post by geysersam »

lateforwork wrote: post #83
rawgabbit wrote: post #61

Earlier quoted context omitted.

It can do loops and recursion. It can use as much memory as it is allowed. It can do general programming via functions and stored procedures.

It can't do loops. Unless you're talking about extensions to SQL such as PL/SQL and T-SQL.

It can do loops. Recursive CTEs has been in the standard since SQL:1999

https://en.wikipedia.org/wiki/SQL:1999

Re: The Rise of SQL:the second programming language everyone needs to know

#123

Post by vedaba »

petcat wrote: post #5

I've loved and used Django ORM and SQLAlchemy for many years. It got me a long way in my career. But at this point I've sworn-off using query-builders and ORMs. I just write real, hand-crafted SQL now. These "any db" abstractions just make for the worst query patterns. They're easy and map nicely to your application language, but they're really terrible unless you want to put in the effort to meta-program SQL using w…

[dead]

Re: The Rise of SQL:the second programming language everyone needs to know

#124

Post by clickety_clack »

danem wrote: post #34
petcat wrote: post #5

I've loved and used Django ORM and SQLAlchemy for many years. It got me a long way in my career. But at this point I've sworn-off using query-builders and ORMs. I just write real, hand-crafted SQL now. These "any db" abstractions just make for the worst query patterns. They're easy and map nicely to your application language, but they're really terrible unless you want to put in the effort to meta-program SQL using w…

Anytime this topic comes up, this opinion is invariably at the top of the comments. However I've never seen a non-trivial application made this way. Mind sharing one? More than the query generation, I think people reach for ORMs for static typing, mapping, migrations, transactions, etc. I'm not doubting that it can be done, I'm just curious to see how it's done.

I’ve started a few projects with SQL over the years, and it makes for a much slower development cycle. Instead of solving business problems, you’re spending too much time focusing on query optimization, and any iteration that touches the db requires all the mapping logic to be painstakingly reconstructed. For me writing queries in SQL is for later optimization. But then again, I’m pretty strict about abstracting even the ORM stuff away into a data access layer, so maybe people run into problems trying to thread ORM models all the way through to their frontend code or whatever crazy things people get up to.

Re: The Rise of SQL:the second programming language everyone needs to know

#126

Post by adammarples »

agosta wrote: post #72
danem wrote: post #34

Earlier quoted context omitted.

Anytime this topic comes up, this opinion is invariably at the top of the comments. However I've never seen a non-trivial application made this way. Mind sharing one? More than the query generation, I think people reach for ORMs for static typing, mapping, migrations, transactions, etc. I'm not doubting that it can be done, I'm just curious to see how it's done.

In addition to the great replies folks are sharing, I've found LLMs are quite good at authoring non-trivial SQL. Have effectively been using these to implemnt + learn so much about Postgres

It's not the sql that is non trivial, it's the patterns where I need to mix and match filtering clauses etc which make running a layer on top of the sql necessary. Unless you're sort of patching together your own query building.

Re: The Rise of SQL:the second programming language everyone needs to know

#127

Post by b-man »

danem wrote: post #34
petcat wrote: post #5

I've loved and used Django ORM and SQLAlchemy for many years. It got me a long way in my career. But at this point I've sworn-off using query-builders and ORMs. I just write real, hand-crafted SQL now. These "any db" abstractions just make for the worst query patterns. They're easy and map nicely to your application language, but they're really terrible unless you want to put in the effort to meta-program SQL using w…

Anytime this topic comes up, this opinion is invariably at the top of the comments. However I've never seen a non-trivial application made this way. Mind sharing one? More than the query generation, I think people reach for ORMs for static typing, mapping, migrations, transactions, etc. I'm not doubting that it can be done, I'm just curious to see how it's done.

I have written the entire backend of a fintech using nothing but postgresql, integration over http and webhook receival included (the last bit was with postgrest, but you get the point)

Re: The Rise of SQL:the second programming language everyone needs to know

#128

Post by DontchaKnowit »

danem wrote: post #34
petcat wrote: post #5

I've loved and used Django ORM and SQLAlchemy for many years. It got me a long way in my career. But at this point I've sworn-off using query-builders and ORMs. I just write real, hand-crafted SQL now. These "any db" abstractions just make for the worst query patterns. They're easy and map nicely to your application language, but they're really terrible unless you want to put in the effort to meta-program SQL using w…

Anytime this topic comes up, this opinion is invariably at the top of the comments. However I've never seen a non-trivial application made this way. Mind sharing one? More than the query generation, I think people reach for ORMs for static typing, mapping, migrations, transactions, etc. I'm not doubting that it can be done, I'm just curious to see how it's done.

Cerner millennium is built entirely this way. There is a custom sql language called CCL that is used for everything interacting with the DB. All the applications just call CCL scripts.

Re: The Rise of SQL:the second programming language everyone needs to know

#129

Post by deepsun »

SoftTalker wrote: post #109
deepsun wrote: post #107

My only problem with SQL is it was designed for human input (same as shell commands), not for machines. Hence the SQL Injection attacks and other peculiarities and inefficiencies. IMO for machine-to-machine talk we should not be using a long text that needs to be parsed carefully and securely on the other side, but rather a structured structure that's easy to de-serialize (like AST packed into a protobuf, but for SQL…

luckily you can use parameterized queries and completely avoid this problem.

Only for simple queries. E.g. it's hard to parameterize table names.

Also it makes an extra round-trip to server to prepare the query.

Re: The Rise of SQL:the second programming language everyone needs to know

#130

Post by sfn42 »

rtkwe wrote: post #33
system2 wrote: post #32

Earlier quoted context omitted.

I agree. Claude Code writes superb SQL queries for very complex data. I was dealing with PostgreSQL recently, and it improved the query from 30 seconds to 5 seconds. I couldn't figure it out myself.

How do you present the interrelations between the tables when you're dealing with complex table structures?

I just go into SSMS and expand the columns for the tables I care about in the left hand explorer, screenshot it and send that to copilot.
Post reply on HN