Re: The wisdom of the object mentors
Date: 29 Jun 2006 07:41:48 GMT
> > > > > 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
See it as the total problem description of what the developer has to write. With persistence taken care of, the total problem description then thus doesn't include how to obtain which data, that's a given. Without persistence taken care of, it's part of the problem description, and the developer THUS has to spend time on that as well. HOW the developer solves it, is not relevant in this.
> > > > 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.
that's what I meant, though you have to know over which relationships you want to join the relations.
> > 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.
myBoardmember.Col1 = value1;
myBoardmember.Col2 = value2;
The thing is that you in one case can work with a full entity (fetch through view or own join) and in another case have to write code to get things inserts.
If I want to insert a new department, manager of the department and a new boardmember working in the department as well as a new companycar for that boardmember, I can do that still with the same statement: myAdapter.SaveEntity(myBoardmember);
and the whole graph is saved in the correct order, PK-FK's are synced at the right time etc. You on the other hand have to make sure the queries are all executed in the right order on the correct tables with the correct values.
THat's also what I meant earlier in my post: if the persistence is part of the problem description, the developer has to spend time on this, write code for this, and thus runs the risk of introducing bugs, if it's not part of the problem description, the developer can focus solely on the problem at hand and accept persistence as a given, how that is constructed is not important. (So if you wish: via a clever proc API)
> > 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.
though if you don't use an updatable view or a view with a couple of instead of triggers, it's at one time necessary to use a view and at another time use a low-level set of updates/inserts on a variety of tables which apparently belong to an entity you CAN'T USE as THE entity, you HAVE TO use fragments of the entity to be able to update/insert.
> > 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
It wasn't a question how to do that, Fredrik ;), I know how to do that (sort the DAG with topology sort, create 2 queues, one for insert, one for update, first run the insert queue, then the update queue, and sync fk's with pk's if pk side is succesfully saved). It was more a question to illustrate that a problem arises if you WANT TO work with an entity 'Boardmember' but HAVE TO work with elements from a lower level of abstraction, namely the 3 tables.
> > Again requires FK constraint metadata knowledge,
> If you don't have this knowledge, you are not the right person for the
Well, I do agree with you that if you want to use a relational model to its fullest in software not implemented inside the RDBMS, you've to know the schema, but more in the way of "which entity is related to which entity and by what relationship type?" for example. Though should it be necessary through which FK fields an entity is related to another entity? Or should it be enought THAT an entity is related to another entity?
> > 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?
You work with the boardmember entity, so you want to change values of that entity, not of the elements on a lower abstraction level. So if you work with a boardmember, it comes down to 1 update statement (as you work with 1 entity) and if you have to work with the lower level elements it comes down to 2+ update statements, which mitigates the whole purpose of having entities on a higher abstraction level.
> > > > 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.
> > > > 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.
I can guarantee you it's not, and it's also portable to other databases. But that wasn't my point, my point was that if you work with an entity on the abstraction level of a NIAM model, why do I have to work with low level elements which reside on a lower abstraction level? That mitigates the whole abstraction level on top of the E/R model.
-- ------------------------------------------------------------------------ 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 Thu Jun 29 2006 - 09:41:48 CEST