Re: The wisdom of the object mentors

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

A database is also a "data structure". Persistence is hidden behind the RDBMS. I am not sure what you mean with "how the data is retrieved".

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

I don't have to look any meta data up. But obviously the programmer has to know the schema he is writing an application for.

> it also takes more work to get things
> saved again.

update boardmember set col1=? where boardmemberid=? update employee set col2=? where employeeid=?

If you show your code, we can estimate if it takes "more work" or not.

> Even if you define a view it's a little hard, because what
> if your rdbms doesn't support updatable views?

I didn't suggest updatable view.

> What if I want to insert a new boardmember entity? Which insert
> to execute first?

Because a boardmember is a manager and a manager is an employee, you need this order:

1. employee
2. manager
3. boardmember

> Again requires FK constraint metadata knowledge,

If you don't have this knowledge, you are not the right person for the job.

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

Doesn't the name attribute belong to the employee entity? What is the bid deal with two updates?

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

Read above: "it comes down to writing code..." and "it has nothing to do with code". Please make up your mind.

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

I never said you had to use E/R to design your database schema. If you have another method that you like better. After all "it has nothing to do with code".

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

What is the big problem with a few update or insert statements? I can guarantee that your solution is much more bloated.

Fredrik Bertilsson
http://frebe.php0h.com Received on Wed Jun 28 2006 - 15:55:15 CEST