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

> The natural key forces you to think about what makes the row unique. What identifies it.

When designing a table - you should always be clear about what the natural key is and make sure it has uniqueness constraint. Mindlessly having a surrogate key without thinking about what the natural key is, is an anti-pattern. So totally agree here.

That doesn't stop you also having a surrogate key though.

Another aspect of natural versus surrogate keys is joins as the key often ends up in both tables.

Using natural keys can mean in some circumstances you can avoid a join to get the information you want - as it's replicated between tables.

There is also the question of whether you surface the surrogate key in the application layer or not - some of the problems of surrogate keys can be avoided by keeping them contained within the app server logic and not part of the UI.

So via the UI - you'll search by car registration number, not surrogate key, but in terms of your database schema you don't join the tables on registration number - you use a surrogate key to make registration numbers easier to update.



Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: