Comment by feoren | Hacker News Reader

Comment by feoren | Hacker News Reader

Parent Full thread

Real talk: y'all build databases like shit. The database is your persistence layer, not your application layer. You give lip service to software engineering concepts like abstraction, DRY, SOLID, or whatever was popular right as you got out of college, but then you throw it all in the trash when you design databases. Your databases are awful. Don't feel bad: literally everyone is doing it. But also do feel bad: you could be doing so much better. It starts by realizing that software engineering principles apply to everything, including (perhaps especially) the database layer. All other database-design advice is secondary to that.

Stop building shit-ass awful databases, please. You don't need to be reading about whether to pluralize your table names or not. You need to be reading about how to even begin to do even a moderately decent job. Go back to your favorite software engineering book and replace all mentions of "class" with "database table" and see if it works. It won't, but why it doesn't will be enormously instructive.

Just to take a different perspective for anyone reading this, your database is more than _just_ your persistence layer. It can be where rules about the business live. Rather than rely on 12 different applications or code in 27 different files to maintain the proper rules, you can enforce those rules right where the data lives, guaranteeing that no matter what moron is writing code, the data will be pristine because the database has checked it before putting it in.

Edit: Just to be clear, I'm not saying it's the right thing to do, at least not in every case. But it's an option; one that's different from the parent's perspective anyhow.

Interesting. Mutation testing on database tables. Instead of testing application code, business rules--and constraints--are mutated against a test suite--

Most databases probably don't have test suites. But, it would be interesting to see if any work has been done on mutating constraints or "dirty data" injection.

This would ideally take the form of some annotated algebra, so that it is db driver agnostic, if possible.

“Don’t feel bad […] but also do feel bad” sums up… a lot of engineering growth. Everyone makes mistakes, and we don’t want junior engineers beating themselves up about it. But if you don’t honor the reasons why they’re beating themselves up—eg pride in their work, caring about any time they cost others with an outage, etc—telling them not to worry looks a lot like an insult. The trick is to help them identify where that sense of responsibility stops being productive (e.g. by driving them to go read docs, or test that edge case in the future) and is just stressing them out (e.g. blaming themselves for a rocky release when the real problem is that deployments at your company are a 20-step process with poor visibility and no undo).

Yeah. We figured this relational stuff out 40+ years ago, but the 23 year old devs are acting like it was born yesterday and they're inventing it from first principles. As the saying goes: read a book.

Reply on news.ycombinator.com