Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Phlip <>
Date: Wed, 14 Jun 2006 13:25:57 GMT
Message-ID: <F7Ujg.44456$>

x wrote:

>> > 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.

If the tests don't break... so what? ;-)

>> (The secret word here is "view", guys...)
> Or synonyms/aliases.

Or indirection.

  Phlip <-- NOT a blog!!! 
Received on Wed Jun 14 2006 - 15:25:57 CEST

Original text of this message