Jerry Nixon performs a change:
Schema change is inevitable. We do not get everything right the first time, and even when we do, the world around the database keeps changing. Requirements mature, products evolve, and assumptions that made sense years ago eventually stop matching reality.
Businesses change too. We acquire companies, merge with other customers and systems, enter new markets, and adapt to new opportunities. Sometimes a schema has to change because the original design was wrong. More often, it changes because the business is no longer the same business that existed when the schema was designed.
That is normal. The challenge is not avoiding schema change. The challenge is making those changes without interrupting the applications and users that depend on the database.
Click through for an example of a schema migration. I disagree with Jerry about doing the work in “the application,” mostly because it’s rarely one application controlling a database. If it is, and if there are no automated jobs, ad hoc PowerShell scripts, secondary applications, or other processes in place that could write data to the same database, then fine. But I typically find that to be less common than the alternative.