Re: The wisdom of the object mentors
Date: 28 Jun 2006 10:03:11 GMT
Message-Id: <xn0eo0fvo8frt4005_at_news.xs4all.nl>
frebe73_at_gmail.com 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, ...)
no. employee manager boardmember id * <-------------ID * <---------------- ID * name managesdeptID companycarid ... ... ...> > work in my code with a Boardmember instance which contains the data
> > I then can
> > 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
it would have been already much better. However that can't be done, as
set name = "Agradizing idiot"
where id = _at_id
> > 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.
> > 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.
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 - 12:03:11 CEST