> You're up against millions of engineering hours in this space.
Tangential, but the fact that many orgs choose to not use native DB features like foreign key constraints, saying that “they’ll handle it in application code,” has always seemed like the pinnacle of hubris to me. You’re going to ignore some of the most battle-tested pieces of technology, and recreate it poorly instead? Quite the decision.
While there are valid reasons to not want to use FKCs, IME much of the time when you peel apart the layers of why someone chose not to, you find that they made several erroneous assumptions that led them to that conclusion. Other times, it’s that they simply didn’t know something existed, because they never read the docs. Windowing functions are a good example: RDBMS can do quite a bit of manipulation to data, rather than just sending huge result sets and having you parse them. There are trade-offs, of course, but you should at least know that it’s even possible before choosing to ignore it.
Tangential, but the fact that many orgs choose to not use native DB features like foreign key constraints, saying that “they’ll handle it in application code,” has always seemed like the pinnacle of hubris to me. You’re going to ignore some of the most battle-tested pieces of technology, and recreate it poorly instead? Quite the decision.
While there are valid reasons to not want to use FKCs, IME much of the time when you peel apart the layers of why someone chose not to, you find that they made several erroneous assumptions that led them to that conclusion. Other times, it’s that they simply didn’t know something existed, because they never read the docs. Windowing functions are a good example: RDBMS can do quite a bit of manipulation to data, rather than just sending huge result sets and having you parse them. There are trade-offs, of course, but you should at least know that it’s even possible before choosing to ignore it.