Re: The wisdom of the object mentors
Date: 27 Jun 2006 10:51:13 -0700
Message-ID: <1151430673.386414.75220_at_i40g2000cwc.googlegroups.com>
> > 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.
What is the difference? A data structure is a data structure. Besides there are also programming languages (PL/SQL etc) with built-in support for relational data structures.
> 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,
Like this?
employee(employeeid, ...)
boardmember(boardmemberid, ...)
manager(managerid, employeeid, boardmemberid, ...)
> 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.
select ...
from boardmember b
join employee e on b.employeeid=e.employeeid
join manager m on m.boardmemberid=b.boardmemberid
What is the problem?
> 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.
All needed data is joined into a list of tuples. The select statement may be hidden behind a view if you don't want your algorithm to know about the details.
Fredrik Bertilsson
http://frebe.php0h.com
Received on Tue Jun 27 2006 - 19:51:13 CEST