Re: Object-oriented thinking in SQL context?

From: <cimode_at_hotmail.com>
Date: Tue, 9 Jun 2009 10:53:31 -0700 (PDT)
Message-ID: <ff829f28-149b-4c85-baaa-e863a51e012d_at_f16g2000vbf.googlegroups.com>


Snipped
> >I am having difficulties understanding you.   Could you state
> >according to what principles you can qualify a system as being high
> >level or low level.  In database theory, low level = physical level =
> >procedural languages.  What is high level according to OO mindset?
>
> Higher level languages deal with more abstract concepts that are closer
> to the way non-specialists view them. So I see the relationship between
> OO and RM as essentially similar to that between COBOL and Assembler.
So are you saying that a high level language in OO mindset determined by the audience that uses it.
What abstracts concepts are you refering to? Could you name them ? What is in your perspective, the difference between COBOL and Assembler ? To me they are both low level languages.

> Whether or not you agree with this characterisation it's the prevailing
> view in software engineering now.
I only agree/disagree with what I understand. So far I have hard time making sense of what you are trying to express.

> I'll extend the analogy a bit further. In the past assembler languages
> were used to coax the last bit of performance from limited hardware. Now
> it's usually easier to upgrade the hardware than to rewrite code in
> assembler. But the people who write compilers still occasionally need to
> rewrite critical sections of code in assembler.
Are you refering to performance aspects ? Are you defining what a high or low level language according to how it performs. I am sorry but you are confusing me.

> By analogy, most developers use OO analysis and coding techniques. They
> aren't concerned with RM at all. But there are still some people who
> need to get maximum performance from database systems. Those are the
> DBAs and the compiler writers who write the driver software that
> interfaces between OO languages and relational databases.
OK. Maybe they should. I often have to fix their blunders in production (loss of data integrity, poor perfomance due to poor SQL database design, you name it)
>
>
> >> >> On the other hand from an OO practitioner's point of view relational
> >> >> theory is a quite little backwater that doesn't have much applicability
> >> >> in the real world.
> >> >There seem to be  a contradiction between this statement and the
> >> >previous.  How can you claim that relational theory is effective into
> >> >handling some database management and then denounce its lack of
> >> >applicability.
>
> >> Please re-read what I actually said.
> >I believe I did.  I just asked a question.  How can something that is
> >applied on a daily basis have a lack of applicability ?
>
> That wasn't what I said. I said that *from the OO practitioner's point
> of view* RM has little applicability. So I don't see any conflict
> between the two viewpoints.
OK. Received on Tue Jun 09 2009 - 19:53:31 CEST

Original text of this message