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

Why you should learn SQL

executeprogram.com

Post reply on HN
Print view View original

91–100 of 137 posts

Re: Why you should learn SQL

#91

Post by BulgarianIdiot »

BiteCode_dev wrote: post #80
BulgarianIdiot wrote: post #64

Earlier quoted context omitted.

> I've spent most of my career hoping that something - anything that's better than SQL will come along and replace it. So, if we put aside Clippy jokes and so on, what's your problem with SQL exactly and what does "better than SQL" mean to you? Because what I saw in the last couple of decades is the NoSQL movement lose air, and half the products representing it adding some sort of SQL dialect support, which if you th…

It's super verbose, doesn't compose well with the host language primitives, is hard to introspect, full of gotchas and very low level.

Databases have no "host" they have "clients" which are heterogenous. So directing this critique at SQL is completely unfounded.

.NET added LINQ and now basic queries are integrated. It was not up to SQL, it was up to .NET

And calling it "very low-level" makes me question if you understand what SQL does and is. It's probably the only mainstream 4th generation language I can think of.

https://en.wikipedia.org/wiki/Fourth-generation_programming_...

Re: Why you should learn SQL

#92

Post by Animats »

frogcoder wrote: post #54

I used to love ORM, I used it everywhere. Writing another language in the language I am coding is wrong. ORM simplifies my programs. No, ORM does not simplify coding! It's a big complex adapter which does not fit many cases. RDBM itself is complex enough, let's put another complex abstraction above it so we can forget about the tables and columns and joins and foreign keys. Complexity added upon another complexity do…

" I still hate to compose SQL in code, but there is no better way."

The one big problem with SQL is intermixing query language and query parameters. This requires escaping and is the source of many PHP vulnerabilities. Instead of

    do_sql('SELECT * FROM tab WHERE name = "abc"')
there should have been a standard where you wrote

    do_sql('SELECT * FROM tab where name = V1", "abc")
or something like that. So you don't do string operations on the query parameters.

Re: Why you should learn SQL

#93

Post by elmo2you »

pjmlp wrote: post #47
laurent92 wrote: post #29

Earlier quoted context omitted.

SQL is useful but we’ve spent decades to abstract it away, because the Java/SQL articulation is always circumvoluted, and juniors do without. Then they load two tables in Java and join them manually in memory; or they fetch the principal record, and use the getter to retrieve the dependency, so Hibernate does one query per row. I accuse all ORMs, especially Hibernate, of making it too easy to skip SQL, and I accuse J…

Anyone that does work on the client that should stay on the server, sending wasted data across the wire has already lost it. To this day I keep writing stored procedures, no need to multiline strings. And for the rest just use either myBatis or jOOP, run away from Hibernate.

You are right, regarding the wastefulness. Additionally, there are extra risks involved when data needs to be transferred between a storage and compute facility.

To a degree I get why architects these days like to separate everything into individual narrow and easier to manage/tuned services. But separating business logic from the data it runs on may equally be a fundamental mistake, when it comes to guarding integrity of both data and the logic acting on it.

There are good argument for advocating that actually ALL business logic should be implemented alongside the data it runs on, inside the database itself. Only the logic specific for presentation should exist separately, in whatever front-end is used. I've seen that done successfully, several times in fact. It does require some programming skills which I've not seen in most programmers these days though. Even less among the young dogs.

Maybe the key question here is: does that say something about proper software design / architecture, or about the state of what programmers these days actually know about the fundamentals.

I believe it's easy to hate on something like SQL from a position of ignorance (to be clear: SQL does have serious shortcomings, without a doubt). Still, in nearly 30 years I've not seen anything come along that is fundamentally better (and gaining enough traction to succeed).

As for those who like to complain that stored procedures are too limited because you would have to implement everything in SQL (I've heard that one a few times too many), plenty of databases have extension to program stored procedures in different languages (e.g. python).

Re: Why you should learn SQL

#94

Post by [deleted] »

helsinkiandrew wrote: post #69
NorwegianDude wrote: post #61

Earlier quoted context omitted.

I'd say that if you think transactions is needed just in 0.1 % of usecases then you probably have a lot of bugs in your application, or you have a very simple one. Transactions are used quite often, and there isn't really any other options.

My apps may be simple and have lots of bugs but I'd still say that the vast majority of SQL calls in all apps are to read data that isn't being written to at all or very infrequently - hours/days/weeks and reading possibly temporally inconsistent data isn't important.

[deleted]

Re: Why you should learn SQL

#95

Post by masklinn »

urthor wrote: post #26
cratermoon wrote: post #23

I've spent most of my career hoping that something - anything that's better than SQL will come along and replace it. It's like FORTRAN, except FORTRAN has had the decency to stay in use where it's really the best choice. But SQL is out there, like Clippy. "Hey, I see you're collecting some data. SELECT TRUE FROM HELP WHERE COLLECTING_DATA IS TRUE

Nobody else has invented any other declarative language it seems. Come on aspiring post-docs, do your thing and launch a new programming language. If MIT can launch Julia someone can launch a language that's not SQL.

> Nobody else has invented any other declarative language it seems.

Postgres was originally built on one: https://en.m.wikipedia.org/wiki/QUEL_query_languages

There’s also D/D4/Dataphor, though i’m less convinced.

Unsurprisingly that mostly died out after sql took over everything.

Re: Why you should learn SQL

#96

Post by xupybd »

Abstracting the persistence layer is important, but also unique to your application. ORMs come with some nice features however relying on a full ORM feature set can lead to leaky abstraction. Not to mention you have to learn another DSL to use most ORMs. Why not just use SQL. A nice custom wrapper around binding query parameters is all I need most of the time.

If you use an Onion or Clean Architecture you'll push the SQL into its own layer and you don't need an ORM.

Re: Why you should learn SQL

#97

Post by throwaway81523 »

aslkdjflkajsdf wrote: post #73

I'd like to see SQL as a first class citizen in a static typed language with tuples & record polymorphism. disclaimer: I hate ORMs. Something of interest: https://smlsharp.github.io/en/

You might look at the now defunct ur/web if you haven't. An old snapshot of the web page:

https://web.archive.org/web/20170429201116/http://impredicat...

Re: Why you should learn SQL

#98

Post by setr »

Animats wrote: post #92
frogcoder wrote: post #54

I used to love ORM, I used it everywhere. Writing another language in the language I am coding is wrong. ORM simplifies my programs. No, ORM does not simplify coding! It's a big complex adapter which does not fit many cases. RDBM itself is complex enough, let's put another complex abstraction above it so we can forget about the tables and columns and joins and foreign keys. Complexity added upon another complexity do…

" I still hate to compose SQL in code, but there is no better way." The one big problem with SQL is intermixing query language and query parameters. This requires escaping and is the source of many PHP vulnerabilities. Instead of do_sql('SELECT * FROM tab WHERE name = "abc"') there should have been a standard where you wrote do_sql('SELECT * FROM tab where name = V1", "abc") or something like that. So you don't do st…

Aren’t you referring to parameterized/prepared queries? Any proper DB driver/library should have this feature.

    do_sql('SELECT * FROM tab where name = ?", "abc")
https://www.php.net/manual/en/pdo.prepared-statements.php

I recall getting curious when I was younger where the deranged advice of “sanitize your queries” came from — realizing that you should be able to simply tell the database that this is a string, not part of the query itself. SQL injection should barely exist as a concept, let alone be the #1 web vulnerability.

IIRC it turned out MySQL supported parameterized queries for ages, but the stdlib php MySQL library just didn’t add support for it. This discovery solidified my understanding that PHP has been giving developers brain damage for decades.

Re: Why you should learn SQL

#99

Post by xupybd »

kumarvvr wrote: post #30
cratermoon wrote: post #23

I've spent most of my career hoping that something - anything that's better than SQL will come along and replace it. It's like FORTRAN, except FORTRAN has had the decency to stay in use where it's really the best choice. But SQL is out there, like Clippy. "Hey, I see you're collecting some data. SELECT TRUE FROM HELP WHERE COLLECTING_DATA IS TRUE

The closest that many have come to is to develop ORM libraries. LINQ + EntityFramework Core is my favorite.

I'm normally not a fan of ORMs but I've had good experiences with Entity Framework.

I really like the automatic migrations.

For small apps and a single dev it hits a sweet spot.

I find .Net really good at being kitchen sink included and business ready. If you're making internal small apps I've yet to find a better platform. Especially if you're in an MS Office heavy environment.

Re: Why you should learn SQL

#100

Post by eurasiantiger »

mr_toad wrote: post #32
eurasiantiger wrote: post #7

SQL is going to eventually die because of its three-pronged relationship model that implies query-time complexity. Learn it if you want, but especially backend and analytics people would be better off learning Gremlin or Cypher. Edit: downvoting this is not going to make it untrue.

For simple queries, row adjacency will beat the graph hands down. And RSBMSs are hard to beat for transactional processing.

Plenty of graph databases, even distributed ones, come with transactional guarantees and ACID to boot. Not everything is eventual consistency.
Post reply on HN