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

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

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