Database Design for Mere Mortals

What Hacker News says

1. apothegmSep 2026
   Database Design for Mere Mortals. The first afternoon I spent reading and puzzling through that book was worth an entire semester of computer science classes on the topic — and caused me to fall in love with relational databases.

   With special mentions to K&R as well as The Manager’s Path.

   thread
2. zer00eyzJul 2026
   To this articles credit, it does start out with normalization and design!

   There needs to be more emphasis how important this is! I cant tell you how often I see it done "badly" (we let our ORM build the db for us). The best text I have ever found on this is "Database Design for Mere Mortals", over the years I have bought more that a few copies and I always end up giving them away to those in need (and there are always people around in pretty dire need).

   The one thing I would say is missing from this article is to not be afraid of using postgres for "stupid" things. Cache, queue's, and so on, especially on the road to launch.

   One should also not be afraid of having more than one Postgres instance, especially if you're using it as a work queue.

   Lastly there is a stupid amount of power in Postgres roles (its "user" system). The manual here is somewhat OK, but really undersells richness that it makes available to you.

   Show morethread
3. wombatpmJul 2026
   Can’t say enough good things about Database Design for Mere Mortals. I keep a physical copy on my desk to give to other developers to read.
   thread
4. zer00eyzJul 2024
   I don't think you need the certs but there are some books, and studies you should undertake.

   1. Database Design for Mere Mortals ... Probably one of the bests books on the how's and why's of the RDBMS. In Cod we Trust!

   2. CCNA. I don't think you need the cert, but you should understand networking.

   3. LDAP, DNS, SSL... These three things are kissing cousins but few people know the history or understand the tooling here. Setting up OpenLdap, Bind and your own SSL server is something you should do ONCE...

   4. Containers and Hypervisors... There is more to life than Docker. I would make the argument that docker as its used is harmful to software development. Spend some time with VM's and LCX... Learn why you would want to use each, and where Docker can be a source of collisions.

   5. Hardware: Find something that interests you and go deep. Have a clean switch/network setup at home. Build something with microcontrollers or at least write software for them (esp32). Pick up 3da printing as a hobby. Revive legacy hardware. There's a million things you can do here... The important thing is that your hands are on things other than the keyboard to get it done!

   6. BSD: Do you need to run a pure BSD install and work with it, no. But there are plenty of NAS, ROUTER and other apliance systems that use it where you can dabble. OpnSense is an amazing product and you can stick your toe in with that, and hone those networking skills!

   If you're not the self directed learning type then all of the above might not get you going... Find a non profit that needs a nerd and do a project involving any of the above for them. As a bonus, if you ask nicely they will write off your time as an unkind donation that has tax advantages (at least in the US).

   Show morethread
5. zer00eyzApr 2024
   > I don’t know sql.

   Buy the book "Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design"

   Read it, read it again, read it till you can normalize in your sleep. Candidly the RDBMS isnt hard, and once you understand how to build one SQL clicks.

   thread
6. zer00eyzMar 2024
   Go read: Database Design for Mere Mortals.

   ERD's are your friend. Learn how to generate one, and how to read it.

   The relations (not relational, not algebra) are IN the design they are IN the ERD (as a tool to visualize). Even if your not visual thinker the ERD might help you find a path between two distant tables.

   Needing a subquery is rare. It happens but a lot of subqueries would be better off as joins. The moment you grasp the design of something you're less likely to want to sub query.

   Explain is your friend. Reading an explain plan is going to give you some good insight into what is going on UNDER the hood. Not only will it help you tune slow queries but it is more insight into how large queries decompose.

   Lastly, there is nothing worse than having to query a badly designed DB. If you do a shit job on the first part everything else is going to be painful.

   Show morethread