Re: The wisdom of the object mentors
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 27 Jun 2006 16:47:57 GMT
Message-ID: <1jdog.2950$pu3.72074_at_ursa-nb00s0.nbnet.nb.ca>
>
>
> 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.
Date: Tue, 27 Jun 2006 16:47:57 GMT
Message-ID: <1jdog.2950$pu3.72074_at_ursa-nb00s0.nbnet.nb.ca>
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. Received on Tue Jun 27 2006 - 18:47:57 CEST