Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors

Re: The wisdom of the object mentors

From: Frans Bouma <perseus.usenetNOSPAM_at_xs4all.nl>
Date: 28 Jun 2006 09:49:18 GMT
Message-Id: <xn0eo0ffs7xxk8004@news.xs4all.nl>


Bob Badour wrote:

> Frans Bouma wrote:
> > Marshall wrote:
> >
> > > Bart Wakker wrote:
> > >
> > > > frebe73_at_gmail.com writes:
> > > >
> > > > > A algorithm could must obviously know about the data
> > > > > structure.
> > > >
> > > > Not at all! I'm currently writing many algorithms that get their
> > > > data passed in as java objects. The algorithm does not need to
> > > > know where the data came from and how it is stored in the
> > > > database.
> > >
> > > "Where the data came from" is not the data structure.
> > >
> > > These methods you are writing, are they declared to receive
> > > arguments of type java.lang.Object? No? Then the objects
> > > support some interface, and that interface is the logical
> > > data structure.
> > >
> > > Yes? Then how do you get the data out of them? Reflection?
> > > Then you have some agreed-upon meta-protocol, whereby
> > > the logical data structure may be queried.
> > >
> > > An algorithm must obviously know about the data structure.
> >
> >
> > Sure, but that's the datastructure of the application containing
> > the algorithm, not the 'datastructure' the data resides in in the
> > db. If I have 3 entities: Employee, Manager, Boardmember, and
> > Manager is the subtype of Employee and Boardmember is the subtype
> > of Manager and I define these entities as 3 tables, one for each
> > entity, where each subtype has a PK which is also an FK to its
> > supertype's PK, I then can work in my code with a Boardmember
> > instance which contains the data which is stored in the employee
> > and manager tables as well. It comes down to writing code which
> > consumes entities on the level of how they exist in NIAM/ORM
> > (Halpin/Nijssen http://www.orm.net), not on the level of an E/R
> > model.
> >
> > The algorithm then works with a 'boardmember' while the data
> > actually resides physically in 3 tables. So the algorithm doesn't
> > know where the data is stored, it just works with boardmember
> > objects.
>
> Two words: join, view.
>
> Idiot. Oops, that's three.

         Ah, and only true in the true RDBMS, I suppose? Have fun UPDATING your boardmember data as one entity through your view on an RDBMS which doesn't support updatable views.

                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#) 
------------------------------------------------------------------------
Received on Wed Jun 28 2006 - 04:49:18 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US