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

Things I wished more developers knew about databases

medium.com

Post reply on HN
Print view View original

351–360 of 464 posts

Re: Things I wished more developers knew about databases

#351

Post by watwut »

mgkimsal wrote: post #25
harikb wrote: post #23

Earlier quoted context omitted.

Not really. That is exactly the point the article is trying to make. Developers need to care about these things - _enough to know who to go get help from_. That is the minimum. Also 10 years is an exaggeration. 2 years working on a non-trivial backend should expose one to these problems. From what I have seen, products built without caring about these will usually get rebuilt a year from the original release - either…

> 2 years working on a non-trivial backend should expose one to these problems. You can be exposed to them, but without understanding them, and experiencing both good, bad, and really bad 'solutions' to them, and understand the impact (on the business, on the code, on security, on maintainability, etc)... you just can't really get all that in 2 years. I know plenty of people who've been 'exposed' to certain type of t…

> You can be exposed to them, but without understanding them, and experiencing both good, bad, and really bad 'solutions' to them, and understand the impact (on the business, on the code, on security, on maintainability, etc)... you just can't really get all that in 2 years.

I don't think this is about becoming expert. This is about learning at least very basics in multiple areas so that you are not completely clueless and know issues exist. When you redefine requirements to "2 years active learning worth of knowledge", you moved goalpost quite far.

> I've been doing this for a bit over 25 years, professionally now, and... there's a lot I don't 'get' with current stuff. But I've seen and lived enough projects, in enough different situations, to have a good idea of impact of tech decisions, and to understand how to make tradeoff decisions.

This is being senior.

Re: Things I wished more developers knew about databases

#352

Post by shifto »

listenallyall wrote: post #344
chaps wrote: post #149

Here's a fun bug I had a few years ago - Had a postgres database which was using pgbouncer for connection pooling. The most senior developer (24yo or so) we had on the project was using Go to connect to the database to write some simple reports, but each report took hours to run, and often had to sleep for 30+ minutes. So, after a while, pgbouncer would kill their connection, and their report would die. No other appl…

>> That ended up fixing the problem Interesting take, since you're still stuck with "simple reports" that take hours to run. What about writing more efficient queries, adding indexes, normalizing the DB... ?

Wouldn't be the first developer to just SELECT * with a thousand joins and then sort data in app(!).

Re: Things I wished more developers knew about databases

#353

Post by 101404 »

dvtrn wrote: post #318
101404 wrote: post #292

Earlier quoted context omitted.

Why not judge people by the result of their work, instead of their age?

Because then it’s harder to deal with our own imposter syndromes if we can’t blame it on the youth and hold their heads in the toilet while giving them the professional-development equivalent of a wedgie. This was discussed at length in last week’s “Grey Beard Weekly” newsletter.

So the "old people" are the bad guys for you, hmm.

Then again, it's mostly "old people" who are discriminated against when it comes to hiring.

Re: Things I wished more developers knew about databases

#354

Post by danielscrubs »

lanius wrote: post #240
eeZah7Ux wrote: post #215

Earlier quoted context omitted.

> The most senior developer (24yo or so) I see the problem there.

Age is a just a number. John Carmack created Doom in his early 20s.

That's a weird take. You don't think Carmack 2020 is wiser than Carmack 1993?

He is currently working on artificial general intelligence.

Re: Things I wished more developers knew about databases

#355

Post by taffer »

karmakaze wrote: post #312
taffer wrote: post #98

Earlier quoted context omitted.

SQL and functional programming constructs are actually quite similar: SELECT -> map FROM -> stream JOIN -> flatMap WHERE -> filter GROUP BY -> collect ORDER BY -> sorted https://blog.jooq.org/2015/08/13/common-sql-clauses-and-thei...

I don't see how JOIN is like flatMap. It's a subset of a cross-product. It's more like do-notation: x

> I don't see how JOIN is like flatMap

This is explained in the blog post I linked, including an example.

Re: Things I wished more developers knew about databases

#356

Post by contingencies »

corey_moncure wrote: post #42
wenc wrote: post #16

I never realized this before but many excellent developers struggle with SQL beyond simple SELECT statements. I have a colleague who is by all accounts a deeply technical person but one day he confessed to me that he didn't really grok SQL and that he'd rather work with a "real" procedural programming language to just store and retrieve data. Part of it may be due to the fact SQL isn't really a programming language b…

I'm an SQL hater in remediation. In a given week I might work with all of the following: SQL, C#, Python, JS (Kendo, Vue, React), XSL, bash, and more. I'm a quick learner and I pick things up fast, always have, I've got a deadline and I don't have the time or capacity to fully internalize the minutiae of all the technologies I have to work with. In other words I depend on the tools to show me the options at my dispos…

May I propose, for your long expression of frustration, a simple fix. Don't use left join. Instead select x.x,x.y,y.x,y.z from x,y where x.x=y.z and ...;

This is the same operation but without the screwup syntax. The whole notion of left join style syntax is an abomination and - excepting for those who have internalized it to the detriment of normal discourse - represents needless cognitive load.

Re: Things I wished more developers knew about databases

#359

Post by Ma8ee »

LouisSayers wrote: post #297
breischl wrote: post #163

Earlier quoted context omitted.

But now you're filling your application with arcane and inscrutable logic, with an extra layer of abstraction via the ORM to make it even less scrutable. I think one should view a SQL DB like a microservice. Instead of REST endpoints (or gRPC or whatever), create stored procedures. These define a strong contract with your DB, the capabilities that it provides to your app(s). Now you know what the query and insert pat…

I remember people I used to work with arguing against stored procedures for two main reasons. 1) Version Control - I guess a lot of the stored procedures were being put straight into the DB without recording a history of the changes. These days you could easily do this using DB migrations I guess. 2) Testing - is unit testing a thing for Stored Procedures? I guess again, you might be able to do this from code as well…

I'm using Red-gate tools for all of the above. They are covering source control and unit testing and a lot more, but only for SQL Server.

My previous employer used some homespun systems for the same. A bit clunky, but easier to do than most people thinks.

Re: Things I wished more developers knew about databases

#360

Post by baud147258 »

shifto wrote: post #352
listenallyall wrote: post #344

Earlier quoted context omitted.

>> That ended up fixing the problem Interesting take, since you're still stuck with "simple reports" that take hours to run. What about writing more efficient queries, adding indexes, normalizing the DB... ?

Wouldn't be the first developer to just SELECT * with a thousand joins and then sort data in app(!).

Or even worst/better, thousand of SELECT with joins returning one result and then sort in app.
Post reply on HN