I've been on both sides of this fence. I work on a legacy MySQL database that has 100+ moderatedly-related tables with zero foreign key constraints. Someone w

I've been on both sides of this fence. I work on a legacy MySQL database that has 100+ moderatedly-related tables with zero foreign key constraints. Someone wanted to change the name of a particular object, so I did a little investigation and found that approximately two dozen tables were storing this name-as-key, with at least half a dozen different column names. So essentially we have to scan every row in the entire database to robustly maintain referential integrity, and I vetoed the largely cosmetic change. Granted, this isn't 100% a FK constraint issue, but I imagine if the original DBA knew what FKs were, I wouldn't be in this mess. On the other hand, I have implemented prototypes that clearly had way too many FK constraints, which leads to a bloated schema of unnecessary tables with 1-2 columns each, and makes object lifecycles a spaghetti nightmare.