>> > You don't change the name of a column by the same reason why you don't>> > change a method name in an interface.>>> I change them each time their ... behavior ... migrates to something >> else.>> Who is "their" ? The names, the columns ?> What is this "behavior" ? "Behavior" of data ?

Let me restate the question. "Data column names are part of the interface to
your database, just as public method names are part of the interface of OO
classes. If you change their names, you risk the modules that call them. So
when would one ever change their names?"

There are two answers. Sometimes you make a mistake, and you must fix it by
improving the name. And sometimes you add features that change the meaning
of such names.

A very simple example: A program with a database goes online with a ZIP_CODE
column, and with a public function verifyZipCode(). So then the program is
popular enough to go overseas, where everyone else calls their ZIP codes
"Postal Codes". So you must rename both your columns and function names.

> How can a name be a mistake ?> Are you talking about name clashes ?

By "must", we mean if you don't, your program now has cruft. Its GUI says
"Postal Code", and its internals might still say "ZIP_CODE". That sounds
mostly harmless, but when you multiply it by thousands of changes over
hundreds of engineer-years, the cumulative effect of this "deferred
maintenance" can ruin the value of a code base.

>> Maybe mistakes with databases are harder to fix than other mistakes.>> Then again maybe they are easier.> All logical mistakes are BIG mistakes regardless of the place they occur.> Do you suggest that databases are "more logical" than applications ?

No, I suggest that programmers must constantly perform practices that lower
the potential cost of any kind of change. That means automated tests,
managing dependencies, constantly cleaning and reviewing, and not living
with poor design.

However, I suspect that some database-oriented developers are more reluctant
to refactor their databases which contain live data, in the field. Because
databases optimize queries at the expense of all else, a team must write
extra code to maintain their upgrade paths.

> Take this example:> min(x,y) if (x<y) return x; else return y;>> Rename x y and min with anything you like as long as you keep them > distinct> identifiers and replace all occurences. You will not change anything.> Then rename < ( , ) if < return ; else with something else and you > screwed> it if you also changed the meaning, not just the name.