Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

At a general level I think these lists make developers more aware of uniqueness and constraints.

When designing data I think these questions (skepticisms) should be front of mind;

1) natural values are not unique.

2) things identified by number are best stored as a string. If you're not going to do math on it, it's not a number. That "customer number" should be treated as "customer id" and as a string.

3) be careful constraining data. Those "helpful checks" to make sure the "zip code is valid" are harmful not helpful.

4) those tiny edge cases may "almost never happen" but they will end up consuming your support department. Challenge your own assumptions at every possible opportunity. Never assume anything you "know" is true.

It's hard to measure time saved, and problems avoided, with good design. But it's easy to see bad design as it plays out over decades.

And (especially today) never optimize design for "size". Y2K showed that folly once and for all.




> 2)

This implies denormalization, which is rarely needed for performance, despite what so many believe. Now you’ve introduced referential integrity issues, and have taken a huge performance hit at scale.

> 3)

I mean, maybe don’t try to use a regex on an email address beyond “is there a local and domain portion,” but a ZIP code, as in U.S. only, seems pretty straightforward to check. I would much rather have to update a check constraint if proven wrong than to risk bad data the rest of the time.

> never optimize for size

Optimize for size when it doesn’t introduce other issues. Anyone working on 2-digit years could have and likely did see that issue, but opted to ignore it for various reasons (“not my problem,” etc.). But for example, _especially_ since Postgres has a native type for IP addresses, there is zero reason to store them as strings in dotted quad. Even if you have MySQL, store them as a UINT32, and use its built-in functions to cast back and forth.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: