Very true - graduated in 1998 and one of the few courses I took back then that still holds up is database design. Can’t keep track of how many nosql products I’ve been through (Elasticsearch, MongoDB etc), but relational databases and SQL is the the thing you can always come back to.
I think this article also makes a good argument for if you really need and ORM framework - chances are high that you will need to modify you framework usage a lot more often with new versions, compared to just using plain SQL.
I genuinely do not understand what kind of magical SQL other people are using, because I've never felt this way.
For one, "SQL" only really exists as a standard for very very basic database usage. The MOMENT you want to do anything remotely interesting with it, every goddamn database vendor has come with conflicting, weird, different ways of achieving the same thing. Or not, because sometimes a database doesn't even have a boolean field.
ORMs are also soooo much better for like 99% of use cases. Writing SQL in another programming language turns into slinging around raw strings. No highlighting, syntax checking or type checking. Alternatively, supposed SQL lovers will then build their own bespoke, buggy version of a query builder that'll get features added to resemble a frankensteinian ORM. And guess what? If you actually genuinely need that one super fast, super custom query, you can still write it yourself in any ORM worth using! And the ORM will still take care of all the other basic menial tasks like mapping stuff back and forth.
I'm not arguing for NoSQL here, mind you. That's often worse, unless your use case fits the product perfectly. I'm arguing that the sun doesn't shine out of SQLs arse, and an ORM is always the better choice.
I've been writing database driven software for >25 years, I've used SQL Server, Oracle, MySQL, Postgres, and SQLite extensively across dozens of projects.
You're right that each DBMS has its own quirks but they are pretty minor, unless you're doing something really weird 95% of what you write for one DBMS will work fine with another.
I'm really curious which database you've used doesn't support boolean but is also supported by one of the big ORM's, that seems odd.
Note that this can be fixed with good tooling and a small amount of setup.
My preference is to slap all non-trivial queries under a queries/ dir. You'll have access to all of your tooling out of the box since it's now just plain SQL.
"SQL" only really exists as a standard for very very basic database usage.
I disagree a lot. Nope. Most of the differences are very minor for like 99.99% of queries (like top/limit/first or some minor aggregation clauses). You can code those easily and get almost engine independent queries.
The differences may exist for reporting, which is very system and business specific so you still need to write them per use case.
Also, boolean is usually not really useful and almost never was giving measurable performance gain. Just use null or 0/1 and you get the desired result platform independent.
The "magical sql" you are referring to is either well structured database or some stored procedures processing.
I see this sentiment so often on this subreddit and I really don't understand. Every time i had to work with a codebase with hard coded SQL it was incredibly painful. While EF makes things so much easier. Usually it works for everything well except batch updates.
Its because the choice of ORM or not is highly dependent on the goals of your system. If you need to manage the existence of multiple entities and relationships + business logic between them within a CRUD application, ORMs help a lot with avoiding rewrites of the same queries and keeping the code dry, which vastly improves maintainability in the long run. If you are working on a service which is doing ETL type work and needs amazing performance over large datasets, obviously raw SQL is much better.
The people who hate ORMs likely were using them on applications which outgrew them, and the people who hate raw sql (like me) have seen what kind of crazy amounts of duplicate code and complexity they can introduce in CRUD systems.
In one way I agree- I have worked with plenty of these frameworks throughout my career. My point was mainly that these frameworks (at least the ones inhale worked with) tend to be much more brittle than plain sql. Sure, if you’re building some kind of product that should be db-agnostic it might make perfect sense to abstract the db away as much as possible.
I've always told my junior devs that if you can make it work in SQL, use SQL. It has been battle tested in production since before any of us were in diapers.
NoSQL has very specific use cases but it's very easy to misuse and end up with a much slower and heavier and harder to scale system than you'd have if you'd written in SQL.
And most modern DBs have support for unstructured data as JSON fields. Unless your use case is so specific that even this support is not enough, there's no reason to go to NoSQL.
NoSQL is much better at horizontal scaling. Not an issue for many use cases but can be critical if you have a hundred terabytes of data or tens of thousands of writes/second
While you are correct, that is rarely ever needed. So few apps reach a size where that truly is a concern.
You can scale the heck out of a Postgres DB before that becomes an issue. People choose their tech stack as if their app was going to be the next Facebook. But even at massive sizes with millions of users a simple Postgres DB could do just fine.
Just curious. Never seen this phrase written before. I assume it's from the French "beaucoup". Is this the cool slang way to spell it or did you just write it that way cause that's how it sounds?
My main issue with NoSQL isn't even using it, it's maintaining. Especially for personal projects that often run for years without issues, I regularly find myself migrating code, dealing with version incompatibilities.
The projects build in SQL just work. Untouched for a decade with multiple major version upgrades of the entire database.
Custom rolled SQL also works like that. Yes, no fancy API and a big file with boilerplate, but it works, for years. Never complains about being unable to parse the database version or flavor.
That's the beauty of coding to a standard (provided you're sticking to the common, standardized stuff of course...).
NoSQL can work like this too, but because there's no standardized nosql language, it means the underlying product can simply add/remove features to suit (which is reasonable under every scenario, except it causes problems for your own).
I usually say that nosql means "noidea" in practice.
"noidea" may be because you have no clue what you are doing or you work with an app which is trying to ingest anything you throw at it.
Still, there is very little finished products which by design are the second variant of "noidea". Like jira equivalent of sorts. Once your product solidifies a bit it is always better to have sql db where the data is stored (except logs and such - for those use ELK or similar)
Here's a tradeoff I used to ignore: AWS Dynamo is essentially free if your project has very few users. If you want to publish smth and only pay per request you end up spendiong $1-3/month if you have dozens of users (proportional to the kind of project), once you find out what works then you can upgrade for performance instead of spending a fixed amount for RDS even if nobody is using it.
of course, at that scale, you can get by for a similar cost by just having the web server and db on a small vm. Possibly at the cost of high availability, but hardly the end of the world at that scale
My only critique of this is that in most stacks, changes on the db are the most labor intensive and risky. One microservice malfunctioning is no big deal, but if your single source of truth starts misbehaving the damage can ramp up fast.
Your original statement implies by default moving business logic to SQL, a take I sometimes see boomers/forum geniuses sharing. But also yeah, nosql can actually mitigate this somewhat but that's more a design pattern thing than a technology thing. Postgres is basically a nosql database imo
NoSQL has very specific use cases but it's very easy to misuse and end up with a much slower and heavier and harder to scale system than you'd have if you'd written in SQL.
The worst case of this I ever saw is a vendor who migrated an application with large sets of structured, timestamped data to MongoDB, then reimplemented the time-range filters on their fronted as a text search on the MongoDB collection, which had about the results you'd expect.
When I asked them why they'd moved to MongoDB, they told me it was because they wanted to be able to attach unstructured data to their existing records. That gave me the opportunity to introduce them to the wonders of JSON columns in Postgres.
Postgres does it all man. I've been playing with pgvector on Amazon RDS since it's so much cheaper than OpenSearch and it's crazy how easy it is to just tack on such capability
I've always told my junior devs that if you can make it work in SQL, use SQL.
sometimes they go a bit overboard with that credo though, but even when they do and the resulting monster of a query is not the right thing, at least they'll probably have learned a trick or two trying to solve the problem in SQL
Yeah that's true I should have written "you should probably use SQL" rather than being so absolute. There are definitely solid use cases for NoSQL, but since it's a lot easier to throw everything in a NoSQL database it gets abused a lot.
I think I've seen NoSQL misused more than I've seen it used properly to be honest lol
Current jobs is SQL all the way. And it's nice to not fight with the an ORM. Instead I have business logic in SQL, that's fun to test. The thing I miss the most: some form of schema management. We just make changes to DB from datagrip. Who knows if we have the same schema in staging and production?
I think this article also makes a good argument for if you really need and ORM framework - chances are high that you will need to modify you framework usage a lot more often with new versions, compared to just using plain SQL.
At this point we have to thank Microsoft for creating LINQ. The same query methods from 20 years ago are still used today to query the database through an ORM.
It's not frequent, but there has been a bit of churn with the ORMs with .NET.
Linq2SQL -> EF -> EF Core. Depending on your career and codebase's life, you may have had NHibernate in there as well. The handling of LINQ was not entirely consistent between them throughout their versions. The first that comes to mind because it bit us, is EF.Core did GroupBy in memory for a surprisingly long time.
I don't want to paint a picture of massive churn here, that's not the case and EF Core has been very stable for many versions and years. But the comparison point is 30 years of stability.
I never use ORM, I used to in the beginnign but then I realised exatcly what you said and now I just write plain SQL and source-control it. You can use templates like you do with webpages so table names, columnnames, etc. can be DRY and secured by the type system (e.g. TS) if you need it.
Did you write the article at https://fagnerbrack.com/learn-sql-once-use-it-for-30-years-9aceb0bdee03 or did you get chatGPT to do it for you? Didn't see that in the FAQ.
I would much rather you wrote the article yourself than get chatGPT to do it instead, no matter how "weird" it may be at least it won't be soulless.
That claim sounds like nostalgia, but it rests on something more durable.
How does the claim sound like nostalgia? Is nostalgia not durable?
And
Same syntax, same result, same mental model. Thirty-one years, zero changes.
I don't know what to call this phrasing other than "shit Claude does all the time"
I'm also autistic, I tend to forget contractions exist and try to be very precise with the words that I use, because I'm very used to being misunderstood. But this article definitely reads as AI to me, too, and I read a lot of content from fellow autists.
Nostalgia for me at least, maybe it's assuming everyone else has the same experience. I used to write SQL more often 10-20 years ago when database schema was the business model. Maybe ppl still do it like that and don't feel like nostalgia? I certainly do.
I use the dot style frequently. If you look at my older posts I always like statements without "and" and "commas". It feels stronger. I tend to use it more often at the end either as separate sentences but mostly as separate paragraphs like:
Maybe short bla bla bla.
Punchline short bla bla.
Look at my posts from 2016 it's all the same thing. Nos I'm including in the body.
Btw I have no knowledge about those rules, it just feels more punchy
I just read a couple of your posts from 2023 1, 2 and they read nothing like your current output.
So if you're not using an LLM, then you've read so many LLM generated texts that you've come to believe that's what good writing is and have started emulating them.
Or we could just skip forward to the bit where you say "Well I write the whole article myself but then get Claude to fix up my grammar..." which is how this usually plays out.
Yes for using claude on the grammar. I used to use grammarly but it's too expensive for one purpose, I won't deny that LLMS did change the way I write. Maybe they do brainwashing? 😱😱😱
No, it's just a fact of life. You read a lot of books from one author and you will start imitating the author's style. You look at a lot of drawings from one artist and you'll start imitating their artstyle. You listen to a lot of music from one musician and you'll start imitating their production style.
All of this is happening without your knowledge, because the brain is just working in the background to assimilate all the inputs you're getting, and when it comes time to generate your own, whatever's the easiest to draw upon is what it'll use. It's a natural consequence of using whatever's closest at hand, mentally speaking.
This is why we read a lot of literature in school, to be able to develop our own writing style from an amalgamation of all the books, articles and authors' works we read.
But because the brain is malleable, if we go back to reading only one author we'll eventually develop their style. This includes ChatGPT, because it has its own writing style. You most definitely have read too many AI generated summaries to the point where it's affecting your own writing style.
Either you need to stop reading AI summaries, or you need to balance it out with reading the actual author's articles, or books or whatever.
It's also a somewhat strange comparison (Javascript and SQL in 1996 vs. 2026). Javascript was in its infancy (created in 95), and nobody really knew where the web was heading (Flash, Applets etc). Not to mention that descriptive languages tend to be somewhat stale (lisp, SQL, Prolog), as you only ask the runtime to do something on a very high level; and you don't care how it's done, only the result.
tbqh even back in the day it was a longheld joke rooted in reality that nobody on reddit reads the articles. most people just respond to the title. that's exactly what's happening here. i'm guessing sub-20% of people engaging with this post actually read any of the text
not that that's good but it's different from people not caring about AI articles... they just aren't reading any articles.
guilty as charged, i don't read articles when i don't have the time for them, but the odd time when i do feel like reading the article and i find out it's AI (co-)authored...it just irks me a bit.
Yep and he always adds useless AI summarizes and when you complain, he's like, if you don't like it downvote and I'll delete, and I'm like no the issue is submitting these AI articles and comments in the first place.
have been using SQL since the late 90's. and well, i took db design at cal back in 1998. that couple weeks we finally tried SQL in MS ACCESS? man i use it to this day. english is my 1st language, but i can say i'm fluent in SQL. recently messed around with MS Data API builder. connected cursor to my MS SQL server instance. it is kinda scary how AI can make sense of my shit. but amazing tool kit all the same.
interestingly...i got into SQL after i did things like dbase III. selecting records and stuff was fun. but when the ability to write a query to get back data--i just didn't know at the time. i was in elementary school helping my parents try to get their associates degree in CS.
Worked at a place that did the whole mongo-back-to-postgres pilgrimage a couple years ago. The folks who'd kept their SQL chops were unaffected. Everyone else had a rough quarter.
Interesting point about tooling longevity - the same applies to Unix pipes and the shell ecosystem. Simple primitives that outlast the trend of the decade.
Best infrastructure decision I ever made was standardizing on PostgreSQL. The JSON field support covers 90% of 'I need NoSQL' use cases without the operational overhead.
The ORM vs plain SQL tradeoff is real - spent half a day debugging an ORM query that would have been a 5-line SQL statement. Sometimes the abstraction leaks badly.
Great point about SQL being battle-tested since before any of us were in diapers - PostgreSQL's query planner has decades of optimization work behind it.
Great point about SQL being battle-tested since before any of us were in diapers - the same applies to the tooling around it. PostgreSQL's query planner has decades of optimization work behind it. 👍
The Bourne shell was not informed by anything like the relational calculus but I'm still using the same patterns I learned 40 years ago in current bash scripts. Similarly I use an ancient but powerful subset of vim.
Meanwhile the functional languages have gone through generations of evolution from LiSP/Scheme to Haskell despite their models being described in some very funky theoretical terms. Category theory for the monad - is that absolutely necessary?
I think the formalism underpinning SQL is a bit of a red herring.
I mean, I love the sentiment. Learning SQL is definitely a skill that you can keep coming back to over time without using it constantly in-between. GUI programming has been the exact opposite, and the few GUI libraries I have become somewhat comfortable with are very obsolete and poorly supported on modern systems.
The Only Programming Language Built on Mathematics, Not Fashion
But we are off to a very bad start here. Lisp, Scheme, SML, Haskell... functional programming is often derided as "fashion", but generally not by the people who actually understand it.
Also, SQL code written specifically to very old versions of Postgres, is anything but guaranteed to work on modern versions. Also portability between different implementations, like between Postgres and Maria, is infamously bad. Yes, the mental model is very consistent, but the details change a lot. In particular, subtle differences in individual data types tend to create edge cases that lead to endless problems with any major database migration.
That said, I'd love for a modern variant of SQL that takes a more principled approach, such as eliminating 3-valued logic by default, being more open to treating arrays and matrices and tables and abstract syntax trees as first-class values that you can shove into a column in a table and manipulate in the query language, being more explicit about concurrent semantics, and being much more precise about specifying what values a particular datatype can take on and the allowable syntaxes, and so on...
TallGreenhouseGuy@reddit
Very true - graduated in 1998 and one of the few courses I took back then that still holds up is database design. Can’t keep track of how many nosql products I’ve been through (Elasticsearch, MongoDB etc), but relational databases and SQL is the the thing you can always come back to.
I think this article also makes a good argument for if you really need and ORM framework - chances are high that you will need to modify you framework usage a lot more often with new versions, compared to just using plain SQL.
Own-Zebra-2663@reddit
I genuinely do not understand what kind of magical SQL other people are using, because I've never felt this way.
For one, "SQL" only really exists as a standard for very very basic database usage. The MOMENT you want to do anything remotely interesting with it, every goddamn database vendor has come with conflicting, weird, different ways of achieving the same thing. Or not, because sometimes a database doesn't even have a boolean field.
ORMs are also soooo much better for like 99% of use cases. Writing SQL in another programming language turns into slinging around raw strings. No highlighting, syntax checking or type checking. Alternatively, supposed SQL lovers will then build their own bespoke, buggy version of a query builder that'll get features added to resemble a frankensteinian ORM. And guess what? If you actually genuinely need that one super fast, super custom query, you can still write it yourself in any ORM worth using! And the ORM will still take care of all the other basic menial tasks like mapping stuff back and forth.
I'm not arguing for NoSQL here, mind you. That's often worse, unless your use case fits the product perfectly. I'm arguing that the sun doesn't shine out of SQLs arse, and an ORM is always the better choice.
MagicWishMonkey@reddit
I've been writing database driven software for >25 years, I've used SQL Server, Oracle, MySQL, Postgres, and SQLite extensively across dozens of projects.
You're right that each DBMS has its own quirks but they are pretty minor, unless you're doing something really weird 95% of what you write for one DBMS will work fine with another.
I'm really curious which database you've used doesn't support boolean but is also supported by one of the big ORM's, that seems odd.
SapientLasagna@reddit
SQL Server, lol. The ORMS map the bit datatype to boolean.
ApeStrength@reddit
SQL Server is never discussed it's hilarious
Federal_Panda@reddit
Note that this can be fixed with good tooling and a small amount of setup.
My preference is to slap all non-trivial queries under a
queries/dir. You'll have access to all of your tooling out of the box since it's now just plain SQL.Python eg:
With neovim, you can also set it up so that tree sitter is aware that any variable named
*_query = "...your str here"now has SQL syntax highlighting.This has a huge advantage: You can open your sql-cli and simply paste the offending query.
P.S. I hate SQL and think that ORMs are more ergonomic, but there are clear performance and tooling advantages to using raw queries.
ptoki@reddit
I disagree a lot. Nope. Most of the differences are very minor for like 99.99% of queries (like top/limit/first or some minor aggregation clauses). You can code those easily and get almost engine independent queries.
The differences may exist for reporting, which is very system and business specific so you still need to write them per use case.
Also, boolean is usually not really useful and almost never was giving measurable performance gain. Just use null or 0/1 and you get the desired result platform independent.
The "magical sql" you are referring to is either well structured database or some stored procedures processing.
Sisaroth@reddit
I see this sentiment so often on this subreddit and I really don't understand. Every time i had to work with a codebase with hard coded SQL it was incredibly painful. While EF makes things so much easier. Usually it works for everything well except batch updates.
ApeStrength@reddit
Its because the choice of ORM or not is highly dependent on the goals of your system. If you need to manage the existence of multiple entities and relationships + business logic between them within a CRUD application, ORMs help a lot with avoiding rewrites of the same queries and keeping the code dry, which vastly improves maintainability in the long run. If you are working on a service which is doing ETL type work and needs amazing performance over large datasets, obviously raw SQL is much better.
The people who hate ORMs likely were using them on applications which outgrew them, and the people who hate raw sql (like me) have seen what kind of crazy amounts of duplicate code and complexity they can introduce in CRUD systems.
TallGreenhouseGuy@reddit
In one way I agree- I have worked with plenty of these frameworks throughout my career. My point was mainly that these frameworks (at least the ones inhale worked with) tend to be much more brittle than plain sql. Sure, if you’re building some kind of product that should be db-agnostic it might make perfect sense to abstract the db away as much as possible.
posting_drunk_naked@reddit
I've always told my junior devs that if you can make it work in SQL, use SQL. It has been battle tested in production since before any of us were in diapers.
NoSQL has very specific use cases but it's very easy to misuse and end up with a much slower and heavier and harder to scale system than you'd have if you'd written in SQL.
Acalme-se_Satan@reddit
And most modern DBs have support for unstructured data as JSON fields. Unless your use case is so specific that even this support is not enough, there's no reason to go to NoSQL.
you-get-an-upvote@reddit
NoSQL is much better at horizontal scaling. Not an issue for many use cases but can be critical if you have a hundred terabytes of data or tens of thousands of writes/second
uniqueusername649@reddit
While you are correct, that is rarely ever needed. So few apps reach a size where that truly is a concern.
You can scale the heck out of a Postgres DB before that becomes an issue. People choose their tech stack as if their app was going to be the next Facebook. But even at massive sizes with millions of users a simple Postgres DB could do just fine.
TwentyCharactersShor@reddit
Er, depends what you mean by "make it work in SQL". The amount of stored procedure crap I have seen in my career is enough to make angels weep.
JaBray@reddit
Hey don't knock stored procedures, I make my living modernizing and maintaining some from 30 years ago!
AlwaysShittyKnsasCty@reddit
You’re like all those COBOL developers making boku bucks in order to simply keep legacy systems running. Keep up the good fight!
mike_november@reddit
Just curious. Never seen this phrase written before. I assume it's from the French "beaucoup". Is this the cool slang way to spell it or did you just write it that way cause that's how it sounds?
Zestyclose_Virus7869@reddit
Im dealing with a similar nightmare of SQL stored procedures written for state machines, order management, messaging etc.
It’s vast and vastly unreadable with references to stored procedures inside stored procedures inside stored procedures labyrinth.
The only upside being, it has been there for ages and required very little modifications.
Luvax@reddit
My main issue with NoSQL isn't even using it, it's maintaining. Especially for personal projects that often run for years without issues, I regularly find myself migrating code, dealing with version incompatibilities.
The projects build in SQL just work. Untouched for a decade with multiple major version upgrades of the entire database.
Custom rolled SQL also works like that. Yes, no fancy API and a big file with boilerplate, but it works, for years. Never complains about being unable to parse the database version or flavor.
Solacefire@reddit
What type of personal projects are you using SQL databases for?
Chii@reddit
That's the beauty of coding to a standard (provided you're sticking to the common, standardized stuff of course...).
NoSQL can work like this too, but because there's no standardized nosql language, it means the underlying product can simply add/remove features to suit (which is reasonable under every scenario, except it causes problems for your own).
ptoki@reddit
I usually say that nosql means "noidea" in practice.
"noidea" may be because you have no clue what you are doing or you work with an app which is trying to ingest anything you throw at it.
Still, there is very little finished products which by design are the second variant of "noidea". Like jira equivalent of sorts. Once your product solidifies a bit it is always better to have sql db where the data is stored (except logs and such - for those use ELK or similar)
jl2352@reddit
Please, within reason. I’m currently fighting to control a system that generates 3,000 lines of SQL.
fagnerbrack@reddit (OP)
Here's a tradeoff I used to ignore: AWS Dynamo is essentially free if your project has very few users. If you want to publish smth and only pay per request you end up spendiong $1-3/month if you have dozens of users (proportional to the kind of project), once you find out what works then you can upgrade for performance instead of spending a fixed amount for RDS even if nobody is using it.
dangerbird2@reddit
of course, at that scale, you can get by for a similar cost by just having the web server and db on a small vm. Possibly at the cost of high availability, but hardly the end of the world at that scale
mascotbeaver104@reddit
My only critique of this is that in most stacks, changes on the db are the most labor intensive and risky. One microservice malfunctioning is no big deal, but if your single source of truth starts misbehaving the damage can ramp up fast.
davidalayachew@reddit
Sure, but doesn't this also apply to NoSQL? I haven't used it enough to know if it is not.
mascotbeaver104@reddit
Your original statement implies by default moving business logic to SQL, a take I sometimes see boomers/forum geniuses sharing. But also yeah, nosql can actually mitigate this somewhat but that's more a design pattern thing than a technology thing. Postgres is basically a nosql database imo
davidalayachew@reddit
Not my statement, but I doubt the statement in question intended that. I think they were more implying what to use -- framework vs raw SQL?
Ythio@reddit
Not it doesn't imply that.
ILikeBumblebees@reddit
The worst case of this I ever saw is a vendor who migrated an application with large sets of structured, timestamped data to MongoDB, then reimplemented the time-range filters on their fronted as a text search on the MongoDB collection, which had about the results you'd expect.
When I asked them why they'd moved to MongoDB, they told me it was because they wanted to be able to attach unstructured data to their existing records. That gave me the opportunity to introduce them to the wonders of JSON columns in Postgres.
posting_drunk_naked@reddit
Postgres does it all man. I've been playing with pgvector on Amazon RDS since it's so much cheaper than OpenSearch and it's crazy how easy it is to just tack on such capability
fiah84@reddit
sometimes they go a bit overboard with that credo though, but even when they do and the resulting monster of a query is not the right thing, at least they'll probably have learned a trick or two trying to solve the problem in SQL
posting_drunk_naked@reddit
Yeah that's true I should have written "you should probably use SQL" rather than being so absolute. There are definitely solid use cases for NoSQL, but since it's a lot easier to throw everything in a NoSQL database it gets abused a lot.
I think I've seen NoSQL misused more than I've seen it used properly to be honest lol
riyoth@reddit
Current jobs is SQL all the way. And it's nice to not fight with the an ORM. Instead I have business logic in SQL, that's fun to test. The thing I miss the most: some form of schema management. We just make changes to DB from datagrip. Who knows if we have the same schema in staging and production?
AyrA_ch@reddit
At this point we have to thank Microsoft for creating LINQ. The same query methods from 20 years ago are still used today to query the database through an ORM.
seanamos-1@reddit
It's not frequent, but there has been a bit of churn with the ORMs with .NET.
Linq2SQL -> EF -> EF Core. Depending on your career and codebase's life, you may have had NHibernate in there as well. The handling of LINQ was not entirely consistent between them throughout their versions. The first that comes to mind because it bit us, is EF.Core did GroupBy in memory for a surprisingly long time.
I don't want to paint a picture of massive churn here, that's not the case and EF Core has been very stable for many versions and years. But the comparison point is 30 years of stability.
fagnerbrack@reddit (OP)
I never use ORM, I used to in the beginnign but then I realised exatcly what you said and now I just write plain SQL and source-control it. You can use templates like you do with webpages so table names, columnnames, etc. can be DRY and secured by the type system (e.g. TS) if you need it.
Salamok@reddit
My first SQL class was in 1990, still use it at least once a week. Not even counting the fact that as a tool it shaped the way I think in general.
Geordi14er@reddit
Rare is it when a codebase doesn’t have to use raw SQL somewhere.
GimmickNG@reddit
What the hell is this AI ass article.
And if it isn't written or "touched up" using AI, then the author needs to get a better writing style than copying ChatGPT.
fagnerbrack@reddit (OP)
Read this before criticising (including the comments and the watch out the date): https://www.reddit.com/user/fagnerbrack/comments/195jgst/faq_are_you_a_bot/
GimmickNG@reddit
Did you write the article at https://fagnerbrack.com/learn-sql-once-use-it-for-30-years-9aceb0bdee03 or did you get chatGPT to do it for you? Didn't see that in the FAQ.
I would much rather you wrote the article yourself than get chatGPT to do it instead, no matter how "weird" it may be at least it won't be soulless.
fagnerbrack@reddit (OP)
I wrote it
mimicmagnet@reddit
It's not that it's soulless, it's shit like:
How does the claim sound like nostalgia? Is nostalgia not durable?
And
I don't know what to call this phrasing other than "shit Claude does all the time"
I'm also autistic, I tend to forget contractions exist and try to be very precise with the words that I use, because I'm very used to being misunderstood. But this article definitely reads as AI to me, too, and I read a lot of content from fellow autists.
fagnerbrack@reddit (OP)
Nostalgia for me at least, maybe it's assuming everyone else has the same experience. I used to write SQL more often 10-20 years ago when database schema was the business model. Maybe ppl still do it like that and don't feel like nostalgia? I certainly do.
I use the dot style frequently. If you look at my older posts I always like statements without "and" and "commas". It feels stronger. I tend to use it more often at the end either as separate sentences but mostly as separate paragraphs like:
Maybe short bla bla bla.
Punchline short bla bla.
Look at my posts from 2016 it's all the same thing. Nos I'm including in the body.
Btw I have no knowledge about those rules, it just feels more punchy
therealgaxbo@reddit
I just read a couple of your posts from 2023 1, 2 and they read nothing like your current output.
So if you're not using an LLM, then you've read so many LLM generated texts that you've come to believe that's what good writing is and have started emulating them.
Or we could just skip forward to the bit where you say "Well I write the whole article myself but then get Claude to fix up my grammar..." which is how this usually plays out.
fagnerbrack@reddit (OP)
Yes for using claude on the grammar. I used to use grammarly but it's too expensive for one purpose, I won't deny that LLMS did change the way I write. Maybe they do brainwashing? 😱😱😱
GimmickNG@reddit
No, it's just a fact of life. You read a lot of books from one author and you will start imitating the author's style. You look at a lot of drawings from one artist and you'll start imitating their artstyle. You listen to a lot of music from one musician and you'll start imitating their production style.
All of this is happening without your knowledge, because the brain is just working in the background to assimilate all the inputs you're getting, and when it comes time to generate your own, whatever's the easiest to draw upon is what it'll use. It's a natural consequence of using whatever's closest at hand, mentally speaking.
This is why we read a lot of literature in school, to be able to develop our own writing style from an amalgamation of all the books, articles and authors' works we read.
But because the brain is malleable, if we go back to reading only one author we'll eventually develop their style. This includes ChatGPT, because it has its own writing style. You most definitely have read too many AI generated summaries to the point where it's affecting your own writing style.
Either you need to stop reading AI summaries, or you need to balance it out with reading the actual author's articles, or books or whatever.
bjarneh@reddit
It's also a somewhat strange comparison (Javascript and SQL in 1996 vs. 2026). Javascript was in its infancy (created in 95), and nobody really knew where the web was heading (Flash, Applets etc). Not to mention that descriptive languages tend to be somewhat stale (lisp, SQL, Prolog), as you only ask the runtime to do something on a very high level; and you don't care how it's done, only the result.
Glizzy_Cannon@reddit
Look at OP, all he does is post AI articles. Have had him tagged for a year now lmao
awry_lynx@reddit
tbqh even back in the day it was a longheld joke rooted in reality that nobody on reddit reads the articles. most people just respond to the title. that's exactly what's happening here. i'm guessing sub-20% of people engaging with this post actually read any of the text
not that that's good but it's different from people not caring about AI articles... they just aren't reading any articles.
SureConsiderMyDick@reddit
I read the article if the commenters recommend it ( in a way that cannot be written by OP IN an alt account )
I don't wanna see the potential wall of ads to discover a pile of garbage.
GimmickNG@reddit
guilty as charged, i don't read articles when i don't have the time for them, but the odd time when i do feel like reading the article and i find out it's AI (co-)authored...it just irks me a bit.
zxyzyxz@reddit
Yep and he always adds useless AI summarizes and when you complain, he's like, if you don't like it downvote and I'll delete, and I'm like no the issue is submitting these AI articles and comments in the first place.
Sotall@reddit
Yeah, he posted this same article a couple days ago.
fagnerbrack@reddit (OP)
bart007345@reddit
I hate CS at university, except relational database design.
big-papito@reddit
Yeah, I don't know. I used to be very good at it - now I struggle to do a left join.
sammymammy2@reddit
Maybe it's not LLMs, maybe people are just really bad at writing good texts.
11111v11111@reddit
3NF ftw!
raphtze@reddit
have been using SQL since the late 90's. and well, i took db design at cal back in 1998. that couple weeks we finally tried SQL in MS ACCESS? man i use it to this day. english is my 1st language, but i can say i'm fluent in SQL. recently messed around with MS Data API builder. connected cursor to my MS SQL server instance. it is kinda scary how AI can make sense of my shit. but amazing tool kit all the same.
TurboGranny@reddit
Yup. Once you get it, you get it. Also, the older you get as a programmer the more you respect the thought that went into SQL.
raphtze@reddit
interestingly...i got into SQL after i did things like dbase III. selecting records and stuff was fun. but when the ability to write a query to get back data--i just didn't know at the time. i was in elementary school helping my parents try to get their associates degree in CS.
not_a_db_admin@reddit
Worked at a place that did the whole mongo-back-to-postgres pilgrimage a couple years ago. The folks who'd kept their SQL chops were unaffected. Everyone else had a rough quarter.
LiveStrawberry4635@reddit
Interesting point about tooling longevity - the same applies to Unix pipes and the shell ecosystem. Simple primitives that outlast the trend of the decade.
LiveStrawberry4635@reddit
Best infrastructure decision I ever made was standardizing on PostgreSQL. The JSON field support covers 90% of 'I need NoSQL' use cases without the operational overhead.
LiveStrawberry4635@reddit
The ORM vs plain SQL tradeoff is real - spent half a day debugging an ORM query that would have been a 5-line SQL statement. Sometimes the abstraction leaks badly.
LiveStrawberry4635@reddit
Great point about SQL being battle-tested since before any of us were in diapers - PostgreSQL's query planner has decades of optimization work behind it.
LiveStrawberry4635@reddit
Great point about SQL being battle-tested since before any of us were in diapers - the same applies to the tooling around it. PostgreSQL's query planner has decades of optimization work behind it. 👍
DeliciousIncident@reddit
What happens after 30 years?
roflpotato@reddit
went through the Larry Taylor's SQL Training way back in aught five and am still using it
johnd126@reddit
SQL is good. I learned to program in C 30 years ago and am still using it weekly.
7h4tguy@reddit
I took several database design classes and am proficient with it. I don't use it at all.
rongenre@reddit
SQL is something I encourage engineering-adjacent people to use as well. So much richer than a report or spreadsheet.
7h4tguy@reddit
Entirely different use cases
mstred@reddit
That somehow reminded me of https://youjustneedpostgres.com.
TooManyBison@reddit
SQL is something I only have to use every couple of years so I always forget and have to relearn.
raphtze@reddit
what do you do as your day to day? it is a rare workday where i do NOT write a little SQL hehe
TooManyBison@reddit
I've been a site reliability engineer/cloud engineer for a while. I don't code much and I stare at a lot of yaml.
raphtze@reddit
ah gotcha. i'm considered a full stack web guy...but i've been staring at SQL for 25+ years. maybe SQL is the new COBOL haha :D
alangcarter@reddit
The Bourne shell was not informed by anything like the relational calculus but I'm still using the same patterns I learned 40 years ago in current bash scripts. Similarly I use an ancient but powerful subset of vim.
Meanwhile the functional languages have gone through generations of evolution from LiSP/Scheme to Haskell despite their models being described in some very funky theoretical terms. Category theory for the monad - is that absolutely necessary?
I think the formalism underpinning SQL is a bit of a red herring.
nullmove@reddit
Unbearable slop, reported. Funny to click on that medium profile and see this:
They really expect kudos from us for the effort of writing that prompt I guess.
sockpuppetzero@reddit
I mean, I love the sentiment. Learning SQL is definitely a skill that you can keep coming back to over time without using it constantly in-between. GUI programming has been the exact opposite, and the few GUI libraries I have become somewhat comfortable with are very obsolete and poorly supported on modern systems.
But we are off to a very bad start here. Lisp, Scheme, SML, Haskell... functional programming is often derided as "fashion", but generally not by the people who actually understand it.
Also, SQL code written specifically to very old versions of Postgres, is anything but guaranteed to work on modern versions. Also portability between different implementations, like between Postgres and Maria, is infamously bad. Yes, the mental model is very consistent, but the details change a lot. In particular, subtle differences in individual data types tend to create edge cases that lead to endless problems with any major database migration.
That said, I'd love for a modern variant of SQL that takes a more principled approach, such as eliminating 3-valued logic by default, being more open to treating arrays and matrices and tables and abstract syntax trees as first-class values that you can shove into a column in a table and manipulate in the query language, being more explicit about concurrent semantics, and being much more precise about specifying what values a particular datatype can take on and the allowable syntaxes, and so on...