Re: The wisdom of the object mentors

frebe73_at_gmail.com wrote:

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

> 
> Yes, statements has to be executed in corrent order with correct data,
> what is the problem?

Actually, in a well-defined language, the order contemplated above doesn't matter at all. Tutorial D allows one to change two or more relvars in the same statement. All that matters is that before the statement and after the statement the database meets its invariants.

As for the other elements, in OO, one has to make sure to use the correct object instances and the correct object attributes. And in OO, order matters very much.

>> That's significant more code, in whatever language you want to use,
>>which thus can lead to more bugs.

> 
> My solution has two lines of code, yours has three lines, and still you
> didn't provide the implementation of SaveEntity. Where is the
> significant more code?

He is a self-aggrandizing ignorant. Truth and facts are unimportant to him. He will just assert whatever he wants and expect people to be too polite to contradict him. (For an excellent treatise on that subject, see Hans Christian Andersen.)

>>the developer has to spend time on
>>this, write code for this, and thus runs the risk of introducing bugs,

> 
> That is why you should use a RBDMS. Someone else already did it for
> you.

Hear! Hear!

>>low-level set of updates/inserts

> 
> Update and insert statements are much more high-level than any OO 3GL
> code.

Hear! Hear!

>>on a variety of tables

> 
> What is the difference of using a variety of tables instead of a
> variety of classes?

A table is a set of sets of object instances whereas an object class is a template for a set of object instances. The extent of an object class is a set of object instances. Thus a table is much more powerful. In any given situation, one uses fewer tables than one would use object classes and only uses only a table instead of a class and an extent and possibly other sets.

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

> 
> But your boardmember is also a mananger and an employee. There are 3
> tables and 3 classes. The tables is not more low-level in any way.

And one can simply work with a view that joins the tables exactly as if one were dealing with a single table.

>>>>Again requires FK constraint metadata knowledge,
>>>
>>>If you don't have this knowledge, you are not the right person for the
>>>job.
>>
>> 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?

> 
> You have to know what columns and foreign keys you are using. It isn't
> that hard.

What's more, the system catalog makes the dbms self-describing and one does not need to have any declared reference between two entities to join them. The simple fact of using values of the same type relates the tables.

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

Since one is working with a single view, one only works with a single entity that has both attributes. The self-aggrandizing ignorant doesn't have the first clue what he's talking about.

>>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.
>
> Somewhere in your code you need all 3 update statements anyhow.

No, I disagree. One need only update a single view with a single statement.

>>>>>> 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.
>>
>> you referred to extra code, I refered to code consuming what's there
>>on the abstraction level of a NIAM model. So in my case I don't need
>>extra code, in your case you think you need extra code.

> 
> I don't really understand what you are talking about here. I have shown
> my code, you have shown yours. My code has fewer lines of code than
> yours. Prove me to be wrong if you don't agree.

Your continued interaction with the self-aggrandizing ignorant isn't helping anybody. He's ignorant. His assertions are simply false. He couldn't care any less whether what he says is accurate or true.

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

The self-aggrandizing ignorant's assumption is false. He is loading the question. Any conclusions the ignorant draws from the assumption are unsound. Received on Thu Jun 29 2006 - 18:59:40 CEST