Re: OO versus RDB

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.

        totally true. However, sometimes the argument that you can change things in a RDM without breaking an app is an advantage which must be utilized so as much code must move towards the RDBMS is used.

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

        "There's nothing more permanent as a temporary solution" ;)

        The thing is that if you use a strongly typed, compile time checked language to formulate your logic in, you get the precise places where names have to be changed, so 'breakage' is only at compile time, which can be fixed (unless, as you previously correctly argued: change something in the interface). Something even most modern RDBMS-es don't provide as they don't recompile a set of stored queries after an ALTER TABLE DDL statement, sadly enough. Not that most 3GLs today offer proper tools for that either, a query formulated as a constant string isn't caught by the compiler as well. It therefore is interesting to see what Linq will bring in the near future, also when MS moves Linq into SqlServer's core engine.

                FB

-- 
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#) 
------------------------------------------------------------------------