Re: Mixing OO and DB

From: topmind <topmind_at_technologist.com>
Date: Fri, 22 Feb 2008 15:51:30 -0800 (PST)
Message-ID: <94fee5d9-aa57-4ae7-b961-8fa259778dd1_at_e10g2000prf.googlegroups.com>


David Cressey wrote:
> "topmind" <topmind_at_technologist.com> wrote in message
> news:09e3c5bf-b099-46b1-bfa3-9076ba08b2c1_at_i29g2000prf.googlegroups.com...
> >
> >
> > David Cressey wrote:
>
> > > The fundamental problem in simulations, as I see it, is autonomy. If
> each
> > > unit in a simulation is not autonomous, the simulation will be
> constrained
> > > at the system level to behave in ways that do not mimic the systems
> being
> > > simulated. Objects are largely autonomous, and that is their great
> > > utility. Objects are more autonomous than functions and procedures from
> the
> > > great programming languages of the 1970s because objects carry state.
> That
> > > is why OOP has displaced structured programming to a large extent.
> >
> > In name only, actually. Most production code for custom apps is not
> > very OOP. It may use a lot of pre-packaged classes, but the code
> > itself is mostly procedural in OO clothing.
> >
>
> A very analogous problem exists in many SQL databases in the field. At
> least, the problem existed 7 years ago, and I believe persists to this day.
> A large number of SQL database designers have only a primitive idea of how
> the relational data model works, or how to use it wisely. They design
> databases as if they were designing a network of linked records, just as
> they would have in the 1970s.
>
> Then they dress their design in relational clothing, and pass it off as
> relational. As a consequence, what can really be done with a relational
> system is frequently so completely misrepresented that the unwary form a
> distorted view of what it's all about.

That is probably true of any IT tool. The majority of those using it misuse it.

>
> > >
> > > In order for objects to collaborate they have to exchange signals
> (data).
> > > In order to usefully exchange data, there has to be a common convention
> > > regarding both the form and the content of the messages passed between
> > > objects. Most of the OO stuff I've seen (which isn't very much)
> > > concentrate on bilateral contracts between pairs of objects as to what
> the
> > > form and content (meaning?) of exchanged messages will be.
> > >
> > > Most of the best database work concentrates on universal contracts
> (although
> > > the word "contracted" isn't widely used) governing the entire body of
> data
> > > stored in a database, and a vast multitude of transactions that
> collaborate
> > > (going forward in time) that adhere to the single contract or some
> subset of
> > > it.
> > >
> > > This looks overly [constraining] to the programmer accustomed to object
> > > oriented thinking.
> >
> > I think part of the problem is that there are not enough "nimble
> > RDBMS" or table engines around, with such ideas as dynamic columns and
> > dynamic tables. It's like judging OOP by only looking at Java and
> > Eiffel instead of Smalltalk and Python.
> >
>
> Your idea of "nimble" and my idea of "chaotic" might overlap. We are going
> to have to watch out for that subthread if we are going to in fact exchange
> useful views on OO and RDM, and not quickly degenerate into name calling.

Sometimes applications need to grow "organically". Its difficult to plan everything all nice up-front in many circumstances. There is a place for rigid, carefully planned apps/DB's, but also for shoot-from- hip ones. Flexibility under a tight budget is sometimes given more priority than accuracy.

-T- Received on Sat Feb 23 2008 - 00:51:30 CET

Original text of this message