Re: OO versus RDB

From: topmind <topmind_at_technologist.com>
Date: 5 Jul 2006 08:47:55 -0700
Message-ID: <1152114475.801776.235450@v61g2000cwv.googlegroups.com>

J M Davitt wrote:
> topmind wrote:
> > J M Davitt 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.
> >>
> >>This can only make sense if one fails to manage their work products
> >>and thinks that such shortcomings are a normal part of their work
> >>life.
> >
> >
> > I am not sure what you mean. If your boss doesn't like the risks of
> > name refactoring, that is the way it goes. One could argue it is the
> > proper application of "time discounting" from accounting. Whether
> > finance-based decision techniques should be used in IT
> > short-vs-long-term planning is a long subject.

> There should be no risk associated with "name refactoring." One
> should not have to "try to hunt down all references." If you have
> to hunt and risk missing something, you're not managing your code.

First of all, it may not be "my code". Second, there may be many languages and tools that don't readily allow easy substitution of column names. For example, many point-and-click tools don't expose their innards to such searching. Any kind of meta programming also may hide such from search. Whether these tools are good or bad is another issue; such tools exist.

A one-language-one-style shop is not that common in my observation.

>
> [snip]

-T- Received on Wed Jul 05 2006 - 10:47:55 CDT