Ask HN: Do you use foreign keys in relational databases?
I&#x27;m going to assume that by &quot;foreign keys&quot;, you mean &quot;foreign key constraints&quot; where the DB itself is insisting on particular relationships.<p>There are a few different schools of thought. I will list them, but the important thing to remember is not to be dogmatic. They are all right or wrong depending on your circumstance.<p>One school of thought says &quot;I want all data in my DB to be normalized. I want it to be right when it goes in so it never breaks the application layer.&quot; That school would say foreign key constraints are critical.<p>Another school of thought says &quot;I want all the data in my DB to be retrieved and inserted quickly. I want the application layer to do any error-checking that is necessary, or, I want to be in a situation where I can always fail gracefully if there&#x27;s errors in data validation.&quot;<p>Still another school of thought says &quot;I don&#x27;t trust those programmers to write good application code, so I will insist on normalized data for that reason,&quot; and yet another says, &quot;I don&#x27;t have control over the DB schema, that&#x27;s some DBA&#x27;s job, so I will just do all my validation in-app.&quot;<p>The point of this being, there&#x27;s tradeoffs either way you go.<p>Personally, I typically would rather have the application layer do the validation and even the joining of data, a lot of the time, when the application is high-volume. At the volumes my organization works with, it is very difficult to write performant SQL queries that use JOINs and other relationships as a developer - even as a DBA! - and often much easier, for me, to write performant application code. The DB is also a pet with many owners, whereas the infra for my applications is owned by my team. So, it&#x27;s better for me to do relationship validation in code myself. (We also do not use a heavy ORM, again for performance reasons. Just Dapper.)<p>At my previous job, the situation was the opposite - we weren&#x27;t under such load at most times that it mattered if the queries were performant, we had Entity Framework building relationship, and EF will blow up if you ask it to build relationships where none exist. So, we needed more normalized data, and that was what we went for. But even then, not in every situation.