Re: The wisdom of the object mentors

From: Frans Bouma <>
Date: 28 Jun 2006 10:03:11 GMT
Message-Id: <> wrote:

> > > 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.

        It's about where the problem lies how the data is retrieved and persisted.

> > 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, ...)

employee            manager               boardmember
id    * <-------------ID * <---------------- ID *
name                 managesdeptID           companycarid
 ...                    ...                 ...

> > 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?

        not only did you have to write a join query which forces you to look up the FK constraints meta data, it also takes more work to get things saved again. Even if you define a view it's a little hard, because what if your rdbms doesn't support updatable views? And even if they support updatable views, most rdbm's support updates of ONE table only through a view. What if I want to insert a new boardmember entity? Which insert to execute first? Again requires FK constraint metadata knowledge, plus if you update the name and some field in boardmember (like s/he gets a new companycar) you've to update two tables while you worked on 1 entity.

        Conceptually, if you would be able to work on the entity 'Boardmember' as if it was a normal entity, so you would be able to do: update boardmember
set name = "Agradizing idiot"
where id = _at_id

        it would have been already much better. However that can't be done, as manager has an FK and boardmember has an FK as well. flattening the hierarchy into one entity won't work.

> > It comes
> > down to writing code which consumes entities on the level of how
> > they exist in NIAM/ORM (Halpin/Nijssen, not on
> > the level of an E/R model.
> Why do you need the NIAM/ORM model? If you use a RDBMS you already
> have the E/R model. Adding an extra model needs some strong
> motivation, otherwise it will just cause a code bloat.

        it has nothing to do with code, it has to do with abstraction levels. If I have the said hierarchy with manager having an FK to 'Department' for the department s/he manages and boarmember an FK to companycar for the companycar s/he has, I can define that in NIAM. Though there are 2 ways to define that in an E/R model. See Nijssen / Halpin "Conceptual Schema and Relational database design".

> > 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.

        views won't help me inserting data nor updating data.


Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website:
My .NET blog:
Microsoft MVP (C#) 
Received on Wed Jun 28 2006 - 12:03:11 CEST

Original text of this message