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

81–90 of 139 posts

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

#81

Post by ChromaticPanic »

tete wrote: post #67
simonw wrote: post #56

Earlier quoted context omitted.

My hunch is that the problems with stored procedures actually come down to version control, change management and automated tests. If you don't have a good way to keep stored procedures in version control, test them and have them applied consistently across different environments (dev, staging, production) you quickly find yourself in a situation where only the high priests of the database know how anything works, an…

> My hunch is that the problems with stored procedures actually come down to > version control Git? (and migrations) > change management Again. Just like any other code. > and automated tests. Just write an automated test like you write any other kind of test?

It's also about separately scaling your business logic from the data layer

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

#82

Post by default-kramer »

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 formerly worked for a travel company. It was the best codebase I've ever inherited, but even so there were select N+1's everywhere and page loads of 2+ seconds were common. I gradually migrated most of the customer-facing pages to use hand-written SQL and Dapper; getting most page loads below 0.5 seconds.

The resulting codebase was about 50kloc of C# and 10kloc of SQL, plus some cshtml and javascript of course. Sounds small, but it did a lot -- it contained a small CMS, a small CRM, a booking management system that paid commissions to travel agents and payments to tour operators in their local currencies, plus all sorts of other business logic that accumulates in 15+ years of operation. But because it was a monolith, it was simple and a pleasure to maintain.

That said, SQL is an objectively terrible language. It just so happens that it's typically the least of all the available evils.

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

#83

Post by lateforwork »

rawgabbit wrote: post #61
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.

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.

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

#84

Post by simonw »

tete wrote: post #67
simonw wrote: post #56

Earlier quoted context omitted.

My hunch is that the problems with stored procedures actually come down to version control, change management and automated tests. If you don't have a good way to keep stored procedures in version control, test them and have them applied consistently across different environments (dev, staging, production) you quickly find yourself in a situation where only the high priests of the database know how anything works, an…

> My hunch is that the problems with stored procedures actually come down to > version control Git? (and migrations) > change management Again. Just like any other code. > and automated tests. Just write an automated test like you write any other kind of test?

That's exactly what I'm saying. If you do those things stored procedures stop sucking.

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

#85

Post by Izkata »

lateforwork wrote: post #65
yawaramin wrote: post #15

Earlier quoted context omitted.

What is your definition of 'programming language'?

It should have arrays, and loops and conditionals.

Slightly simplistic: table rows cover arrays, recursive CTEs cover loops, and JOIN/WHERE cover conditionals.

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

#86

Post by ogogmad »

therobots927 wrote: post #4

The mere existence of Pandas makes me extremely grateful for SQL, because my job would be absolute hell if I had to use pandas or a similar syntax. It’s hard to overemphasize just how perfect SQL is for the job that it does.

I don't think SQL is "perfect" and I'm not sure it's rational to even be saying that. For instance, why is it that the syntax for an SQL query is "select A from B" when many SQL-inspired syntaxes have switched to something like "from B select A" to make it more compositional?

The relational model is pretty simple though. Pandas is an awful mess.

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

#87

Post by bottlepalm »

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…

I love SQL and use it all day long to answer various business questions, but I would never use raw SQL in my code unless there is a good reason for it (sometimes there is). ORMs are there for maintainability, composability, type safety, migrations, etc.. trying to do all that with raw SQL strings doesn't scale in a large code base. You need something that IDE tools can understand and allow things like 'find all references', 'rename instances', compile time type checks, etc.. Raw SQL strings can't get you that. And managing thousands of raw SQL strings in a code base is not sustainable.

ORMs are one of those things that a lot of people think is a replacement for knowing SQL. Or that ORMs are used as a crutch. That has nothing to do with it. Very similar to how people here talked about TypeScript 10 years ago in a very dismissive way. Not really understanding its purpose. Most people haven't used something like Entity Framework either which is game changing level ORM. Massive productivity boost, and LINQ rivals SQL itself in that you can write very small yet powerful queries equivalent to much more complex and powerful SQL.

Post reply on HN