Re: OO versus RDB

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

I happen to like dynamic typing (or type-free). It makes code closer to psuedo-code, more meta-able, and briefer in my opinion. Plus, often many tools and languages use the same DB. One cannot compile the whole world. Further, some dynamic SQL generation techniques, such as Query By Example, are very tough to make statically analyzable.

But, let's not start another dynamic-versus-static typing holy war. There are plenty already on c2.com.

>
> --
> ------------------------------------------------------------------------

-T- Received on Tue Jul 04 2006 - 07:37:25 CEST