Today's anonymous submitter works for a large company. It's one of those sorts of companies which has piles, and piles, and piles of paperwork and bureaucracy. It also means that much of their portfolio of software is basic CRUD applications. "Here's a database for managing invoices." "Here's a database for managing desk assignments." "Here's a pile of databases which link our legacy applications to our new ERP system."
Which brings us to our representative line. It is not a representative line of code, but a representative line of the design specification. This is the design specification for yet another database-driven application.
7.7 REFERENTIAL INTEGRITY CONSTRAINTS
Referential integrity constraints are not applicable for [REDACTED] Application.
Upon seeing this, our submitter predicted that they'd be having a lot of TDWTF submissions in their future.
The worst part? This isn't the only time this has been included in the design spec. Several database driven applications have had this line in their spec. No one is able to explain exactly why referential integrity constraints are not applicable. At best, there are a few batch jobs that don't define a schema themselves, though they need to comply with it. Maybe someone is just copying and pasting from an old design spec and hoping no one notices or cares?
Good news: it's likely that no one will notice, or care. At least not until something breaks in production.
[Advertisement] ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.