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

341–350 of 464 posts

Re: Things I wished more developers knew about databases

#341

Post by quickthrower2 »

arvinsim wrote: post #10
falcolas wrote: post #7

(The 80/20 rule applies below, some developers do care) Developers... just don't care. They want to spin up an ORM, point it at a URI, and forget about it. I've fought this for over a decade now as a DBA, SRE, DevOps, and architect. Most of the developers don't want to deal with anything infrastructure-wise; they want to spend all the time they can just focusing on the problem they're writing software to solve. Obser…

Perhaps development work has reached complexity where it demands full-time attention? Perhaps there is a reason why DBA, SRE, Devops and Architects are separate roles?

Hell Yes. Break it down further: the front end demands that. You could split further into front end architecture, front end UI performance (DOM etc.), web performance (taking into account network etc.), tooling. Even getting NPM to play nice could become a full time expertise!

The "developer". Can do anything that involves smashing at a keyboard! It's like calling a politician a "talker". Oh well you could do ground control for the next moon launch then, that's just a "talker".

Re: Things I wished more developers knew about databases

#342

Post by yen223 »

randomdata wrote: post #333
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 suspect this was what attracted developers to noSQL databases like Mongo in the first place -- it's more attuned to a programmatic mindset. I suspect it was mostly because the tree-like structures people were trying to represent are an absolute pain to work with when you have to shove them into two dimensional rows and columns. I doubt SQL itself had much to do with it as ORMs were already all the rage when Mongo…

I couldn't agree more. I think people underestimate how much complexity got introduced thanks to the object-relational mismatch.

It would be really nice if there were databases that attempted to expose a data interface that is more tree-friendly. That's why I'm keeping an eye out on projects like EdgeDB and DGraph, and even Hasura.

Re: Things I wished more developers knew about databases

#343

Post by brabel »

codegladiator wrote: post #274
brabel wrote: post #261

Earlier quoted context omitted.

Just because you saw a few exception does not mean the rule does not hold in general. Or are you saying most people don't learn with time (a corollary of your theory that age is not a big factor)?

> most people don't learn with time I think this is correct. The curve flattens with age (in my opinion). > you saw a few exception I think the seniors you met (the knowledgeable ones) /were/ the exceptions. Most seniors I have seen have convinced themselves that they know all there is to know.

> Most seniors I have seen have convinced themselves that they know all there is to know.

Yeah, seems we've met different kinds of seniors... I don't know any senior who wouldn't understand that "the more you know, the more you understand just how much you still don't know".

Re: Things I wished more developers knew about databases

#344

Post by listenallyall »

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... ?

Re: Things I wished more developers knew about databases

#345

Post by necovek »

kerng wrote: post #276
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…

Go code often reinvents/reimplements a lot of things from scratch, reintroducing problems that have been addressed long ago in other systems. It's like this new trend, let's rewrite everything in Go to be cool. Financially makes little to no sense.

You lose a lot of allure of Go if "the world" is not implemented in it (mostly safety) — I think that is the core reason everything is reimplemented in Go.

Of course, the real reason is the same reason even Go exists — we always think we can do something better the next time :) But hindsight is not 20/20 when it comes to software development.

Re: Things I wished more developers knew about databases

#346

Post by ikiris »

chaps wrote: post #257
nuggien wrote: post #255

Earlier quoted context omitted.

Nothing about go is magical, and you probably solved the problem blindly.

Wow, okay. You alright over there? Edit, because meh: I'm making no claims about go itself. No idea what makes you think that's what I'm saying, since I'm clearly talking about a library, and not even any stdlibs. "Magic" is just a term useful for describing systems that sweep much of their abstractions under the carpet in a way that probably has gotchas. Granted, the term itself is magical. In terms of fixing the pr…

Select 1 is a really hacky keepalive that relies on several assumptions, I'm not surprised it wasn't expected.

Re: Things I wished more developers knew about databases

#347

Post by reallydontask »

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... ?

> What about writing more efficient queries, adding indexes, normalizing the DB... ?

Adding indexes seems like the best effort/reward benefits of those.

In any case, I can easily imagine the following workflow:

1. Kick off report after first logging in in the morning

2. Get on with your day

3. Check report after first coffee break

Re: Things I wished more developers knew about databases

#348

Post by watwut »

0xy wrote: post #321
eeZah7Ux wrote: post #215

Earlier quoted context omitted.

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

Shameless age discrimination. Very smart people exist at all ages. I've seen 21yo junior grad developers outperform 45yo 'senior' developers.

Seniority is not about how smart you are. And most programmers of any age are neither prodigies nor geniuses.

Re: Things I wished more developers knew about databases

#349

Post by dcolkitt »

throwaheyy wrote: post #194
vsareto wrote: post #12

Earlier quoted context omitted.

Many interests are pulling developers' attention in several different areas all the time. Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), language concerns, new things All of these like to say "if only the developer could do $MY_AREA better, they'd be better developers and we'd have better software". Each of them wants to pile on…

Exactly. Without abstractions, developers would never be able to get anything done. Every task would be dozens of new rabbit holes.

The problem is that all abstractions are leaky in some way or another. If you're going to use an abstraction, you should at least learn enough about it to know where to put the buckets.

Re: Things I wished more developers knew about databases

#350

Post by pbowyer »

debaserab2 wrote: post #214
vsareto wrote: post #12

Earlier quoted context omitted.

Many interests are pulling developers' attention in several different areas all the time. Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), language concerns, new things All of these like to say "if only the developer could do $MY_AREA better, they'd be better developers and we'd have better software". Each of them wants to pile on…

I don't agree. If you're designing data structures in a code base you shoulder some of the responsibility for the persistence characteristics of that data. There's a lot of devs that think database design is the same as starting a new ORM class and generating a migration file. > Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), lan…

> There's a lot of devs that think database design is the same as starting a new ORM class and generating a migration file.

Yes, this. Add to the list those who have drunk the DDD koolaid and the database is "merely an implementation detail".

Post reply on HN