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

31–40 of 464 posts

Re: Things I wished more developers knew about databases

#31

Post by FpUser »

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…

add to that "do not want to declare/worry about types", "cant be bothered about RAM usage/cache coherency/etc", "concurrency" etc. etc. All of those are "premature optimizations".

Re: Things I wished more developers knew about databases

#32

Post by petepete »

rietta wrote: post #21
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…

I sometimes feel in the minority. I love databases. When I work in the Ruby on Rails ORM ActiveRecord I can actually visualize the SQL it is generating in my head and also do all sorts of tricks when needed.

That's the key. ORMs get a bad name but most of the time you just want to display a list of things, or one thing in more depth or maybe create a new thing.

ORMs unfortunately, have a habit of getting in the way when you want to do something they don't natively support. When they just ignore things the database provides people just end up reinventing the wheel. Rails' implementation of enums is a good example of this.

Re: Things I wished more developers knew about databases

#33

Post by hobs »

mattferderer wrote: post #8

> AUTOINCREMENT’ing can be harmful I'll add that they should never be trusted to not jump around either! I imagine everyone makes this mistake at least once in their life. There is a very high chance that the database will skip a few numbers from time to time. You will then have someone from an accounting department asking where Record #XX is.

There's a simple fix - Don't you ever expose primary keys to the users. Ever. Seriously, ever.

A primary key is not an order id, it isnt a person identifier, it isnt a paycheck - its a thing the database should be using behind the scenes.

All of the things I just mentioned change - besides the primary key.

You'll never have this problem if you separate your business logic from your keys.

Re: Things I wished more developers knew about databases

#34

Post by bdamm »

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…

I wish I could slap anyone who gives a hoot about tabs vs spaces. Fortunately modern languages like go are removing the version control problem that not caring about style and using auto-formatting IDEs produces.

Re: Things I wished more developers knew about databases

#35

Post by meddlepal »

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…

From my experience it's just unfamiliarity with the SQL language. I've spent thousands of hours writing PHP, Java, Scala, Kotlin, Python and Go and doing fairly complex things with them since I started programming.

SQL maybe a few hundred hours? And off and on again rather than constantly so I don't always remember beyond the basics. The concepts make sense to me but the language always feels foreign.

Re: Things I wished more developers knew about databases

#36

Post by hobs »

earhart wrote: post #26
AtlasBarfed wrote: post #3

One thing I've noticed that in the medium term of a software service (2-5 years) is that your software should have the ability to do double-writes to and flip reads between two different datastores. That will afford migration with as close to transparent migration with as reduced a downtime or no downtime.

That gets tricky if one of the writes fails.

Generally you get two phase commit involved here, or an asynch mirror that you can restore over if there's failure.

Re: Things I wished more developers knew about databases

#37

Post by LoSboccacc »

stronglikedan wrote: post #19
mattferderer wrote: post #8

> AUTOINCREMENT’ing can be harmful I'll add that they should never be trusted to not jump around either! I imagine everyone makes this mistake at least once in their life. There is a very high chance that the database will skip a few numbers from time to time. You will then have someone from an accounting department asking where Record #XX is.

I'd posit that autoincrements are fine for primary keys, but primary keys aren't fine for auditing.

how would you generate hole-free sequences for use cases like that of parents (invoicing)?

Re: Things I wished more developers knew about databases

#38

Post by dirtydroog »

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'd put myself in this category. I just never liked databases, they never interested me.

Re: Things I wished more developers knew about databases

#39

Post by hknd »

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 used to write SQL at Google/FB, and I did and still do struggle with it.

I think it's because I usually touch SQL like once a month and by the time I need it I already forgot everything :shrug:

Re: Things I wished more developers knew about databases

#40

Post by csours »

stronglikedan wrote: post #19
mattferderer wrote: post #8

> AUTOINCREMENT’ing can be harmful I'll add that they should never be trusted to not jump around either! I imagine everyone makes this mistake at least once in their life. There is a very high chance that the database will skip a few numbers from time to time. You will then have someone from an accounting department asking where Record #XX is.

I'd posit that autoincrements are fine for primary keys, but primary keys aren't fine for auditing.

Auto-increments are fine for primary keys, until they aren't. I think the list of items from the linked article are things that may cause delayed problems.
Post reply on HN