Is it a common or normal practice to encounter schema changes, especially renamed or removed columns, in a production database, without having been notified of the change? If unexpected schema changes are anticipated in the production database, how are they guarded against, other than basic exception handling?
I've worked mainly with credit union software, DoD software, high volume e-commerce web applications, real estate systems, robotics, and more recently CMMS, GIS, and SCADA systems. Although the '90s and early 2000s were more of the wild west, everything I have been involved with over the last 10 years or so has required change management. Modifications to a production database without change control is not allowed by policy and by security controls.
Comments in the accepted answer to this question – Why is “Select * from table” considered bad practice make me wonder how much of this is academic and how much is reality.
Best Answer
If I may be so bold ;)
The problem isn't really about unexpected schema changes to production, though that's certainly a symptom.
In reality it is:
"Why aren't different members of my organization communicating about changes that affect each other"
Once you view it that way then it makes more sense to look at:
etc.