Re: Dreaming About Redesigning SQL

"Bob Nemec" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Mikito Harakiri" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> A comment on two of your points...
>
> > > What about it?  You seem to think objects are inflexible.
> > They are inflexible. After you completed object design, you whole
> stereotype
> > can't be changed. When business requirements change you would be
thinking
> in
> > terms "How would I change implementation and keep my interfaces
> untouched?"
> > and this is not necessarily the optimal problem solution.
>
> That has not been our experience.  We're replacing an 8 year old Smalltalk
> <> RDB application with a Smalltalk <> GemStone/S application, and one BIG
> win has been the malleability of the OODB.  Non-trivial RDB schema changes
> were a nightmare in comparison, primarily in the OO <> RDB interface
layer.

So, blame the interface layer. You or your colleagues obviously made some
very bad decisions 8 years ago.


> FWIW: the OO mapping tools available ten years ago when the first project
> started were not that useful; we rolled our own.  I suspect a more modern
> tool would have made this step easier.  I'm not sure they'd improve the
> performance much (the OODB is much faster for us).

Again, I suggest that signifies the poor decisions made by your team 8 years
ago.


> > I'm sorry, but there is not much logic to encapsulate into business
> objects.
> > They are data. Unless you design your objects to be GUI aware as
suggested
> > in Allen Hollub's articles at Javaworld.
>
> Depends on the domain.  Our application (a financial app) has some fee and
> exposure objects that are very non-trivial (the calculations are mind
> numbing).  It's the reason we picked Smalltalk and GemStone... we feel
> they're good tools for handling the complexity.
>
> Let's keep that in mind: the problem domain should dictate the tools.  The
> question should not be "what's the best solution", but "what's the best
> solution for this problem".

What about your problem domain dictates using something other than logic and
mathematics?