Re: OO versus RDB

Bob Badour wrote:
> topmind wrote:
> >>>>This sort of situation is actually rather common at the enterprise
> >>>>level.
> >>>
> >>>Changing names of columns but keeping the sematics is extremly rare,
> >>>just because it breaks the interface to the applications.
> >>
> >>So do all changes to enterprise schemas, which is why /any/ change to
> >>such a schema is a big deal. The DBA already had to change the schema
> >>to provide burdenedSalary and chose that opportunity to clean up the
> >>semantics.
> >
> > Perhaps I missed the purpose of this debate, but changing the name of
> > *any* interface in any paradigm or language can result in headaches. We
> > use names to reference things. If 50 other applications or routines or
> > classes refer to "fooSalary" and we later realize that it should have
> > been called "barSalary", then we are faced with a *universal* dilema of
> > whether to hunt down and change all 50 references, or leave it with a
> > bad name. This is not a problem unique to databases.
> >
> > I generally suggest leaving it with the bad name and putting a note in
> > the schema (if provided) or routine or class about the actual nature of
> > the misnamed thing. If you try to hunt down all references, you may
> > miss some and your boss will be pissed when things break.
>
> Coward. Seriously, though, my decision process for whether to fix the
> name does not involve even a moment's consideration for how my boss will
> respond. Either the problem is benign in the sense that it won't confuse
> people too much and is unlikely to spread, or it is malignant in the
> sense that it will confuse and will likely spread through the code using
> contradictory semantics. It makes sense to excise the latter regardless
> of what the boss might think.
>
> If one knows what one is doing, a smart boss will accept one's
> judgement. Of course, that only works for those who have a clue. If one
> is not absolutely certain that one has a clue, it's probably best to
> consider what the boss might think.

After the nasty IT crash of 2000-2004 and Congress chomping at the bit to crank up the H-1B quotas for brib.....lobbyists, if my boss does not like such things, I don't do it. Or at least maybe do it incrementally while working on various apps for other purposes, cleaning and testing changes in one shot, as described in a nearby reply.

>
>
> > The only universal way around this dilema that I see is to use "dumb
> > keys", names that carry no meaning such that they can't have the wrong
> > meaning by design. However, it is hard to conceptual work with
> > variables and interfaces with names like "A348282" and "SDFASD".
>
> We have tiny little skulls with only a couple pints of gray matter. That
> sort of thing would only work for the smallest of problems. Usually, we
> need as much assistance as we can get.

A compromise is a hint and a number. For example, suppose you are given a list of arbitrary-looking biz rules about calculating salary dedictions. If you cannot find any meaningful and lasting name, then perhaps call them deduction01, deduction02, deduction03, etc. I've seen cases where it may use a paragraph in a legal document, such as deduction_J47, for rule 47 under section J. (However, in edition 2, the numbering may all change.)

When you work with marketing or laws/legal, many of the biz rules seem fairly arbitrary, probably a compromize cooked up by the suits during a late night at the bar.

-T- Received on Tue Jul 04 2006 - 08:09:00 CEST