Re: The Fact of relational algebra (was Re: Clean Object Class Design -- What is it?)
Date: Mon, 01 Oct 2001 05:36:42 GMT
Message-ID: <3BB800E6.E6F67388_at_Technologist.com>
Content-Type: multipart/alternative;
boundary="------------1AF4C94CC8E7CFBB7C79F545"
--------------1AF4C94CC8E7CFBB7C79F545 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit
Bob Badour wrote:
> "Adrian Veith" <adrian_at_veith-system.de> wrote in message
> news:9nl4hf$ndq$1_at_wrath.news.nacamar.de...
> > I have never talked about pointers. I talked about a reference.
>
> A reference is a pointer.
> > I do mind. I do not attempt to redefine programming language terms
> > when posting to programming groups, and I ask that you not attempt to
> > redefine database management terms when posting to database management
> > groups.
Hmmm. Looks like a redefinition to me. A reference is a reference. It is not a pointer. It has more in common with an automatically created unique ID used as a primary key than with a pointer.
Since your premise is false, the rest of your argument is moot.
> > - it *must* never change throughout the lifetime of an object.
>
> How does it achieve this when I embed the object in my Excel spreadsheet,
> print out the spreadsheet and fax it to someone else?
You cannot embed the object in your spreadsheet. OO 101: Objects have identity. You may copy values to your spreadsheet, you may include the reference to the object in your spreadsheet (if it supports that) so it can dynamically update the spreadsheet as the object state changes, but if the object is *in* the spreadsheet, then it is *not in* the DB.
Your printout does not *contain* any objects, merely statically captured state rendered in a printed form. The fax is a copy of that. These notions have nothing to do with database management and are red herrings.
If the object referred to by your spreadsheet is subsequently deleted from the database, the spreadsheet is no longer valid. Excel already has notions of broken links (ever seen a #REF in a cell?).
> > - it should give you an error if try to access an object, that has been
> > deleted.
>
> As would any dangling pointer, which is just one reason why pointers prove
> so inflexible and ineffective.
No, pointers don't know they are dangling which why they are so inflexible and ineffective.
> How exactly does this new reference type differ from the relational method
> of simply exposing the object directly?
Exposing the object directly violates encapsulation. It exposes implementation details that are properly abstracted behind the object interface.
I don't expect you to agree with me or to see the subtlety of the difference, but it is the answer to your question.
> > The construct of the "reference" brings the task of key-generation to the
> > DBMS.
>
> Unfortunately, it hides the identity of data from the user at the same time.
> A DBMS can generate unique key values without resorting to pointers.
DBMS-generated unique key values provide no data identity values to the user either.
> > You can look at a reference and it tells you: who or what it is and
> > when it is.
>
> I sincerely doubt that many human users can tell anything by observing a
> reference.
I sincerely doubt that many human users can tell anything by observing a DBMS-generated unique key either.
> > Since my design skills are week ( and I am not an advocat for RDBMS like
> > they exist now), please show us your simple approach in SQL.
>
> Since I am not an advocate of SQL, why should I? If you want to criticize
> SQL databases for lack of domain support, be my guest. I would encourage
> you.
And if you cannot offer any viable alternative, why are you wasting everyone's time? The request for SQL was because that is the lingua franca of RDBMS. There is no other common (ANSI/ISO?) language for interacting with databases, is there? If so, what products support it?
> > There are some situations, where navigation is useful. If the task you have
>
> > to perform needs navigation, why should a DBMS (OO or R) hinder you ?
>
> No task requires navigation. Why should any dbms require it?
That is a bold and omniscient claim. How do you propose to support it? How does one prove that the universe of problems may be solved in precisely one way?
> > For example, how do you implement a topological sort with a RDBMS. (Maybe
> > there is a solution, but why should I hire a relational algebra pro, if the
>
> > task is easy with navigation)
>
> You do not need an expert on RDBMS to implement a topological sort, you need
> an expert on graph theory.
Substitute one expert for another and what have you proven? That the task is still outside the reach of the average implementer who needs to solve it?
> > - i am not derived from ClassX, but i can look like and act like ?
>
> If you look like and act like, you are derived from, or you are ClassX.
> Remember physical independence!
There is a significant difference between "I am of (derived from) Class X" and "I can be converted to Type X (or I play one on TV)". This is well before we get to physical implementation issues.
-- Jim Melton, novice guru | So far as we know, our e-mail: Jim.Melton_at_Technologist.com | computer has never had v-mail: (303) 971-3846 | an undetected error. --------------1AF4C94CC8E7CFBB7C79F545 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <p>Bob Badour wrote: <blockquote TYPE=CITE>"Adrian Veith" <adrian_at_veith-system.de> wrote in message <br><a href="news:9nl4hf$ndq$1_at_wrath.news.nacamar.de">news:9nl4hf$ndq$1_at_wrath.news.nacamar.de</a>... <br>> I have never talked about pointers. I talked about a reference. <p>A reference is a pointer.</blockquote>Received on Mon Oct 01 2001 - 07:36:42 CEST
> > I do mind. I do not attempt to redefine programming language terms
<br>> > when posting to programming groups, and I ask that you not attempt to <br>> > redefine database management terms when posting to database management <br>> > groups. <p>Hmmm. Looks like a redefinition to me. A reference is a reference. It is not a pointer. It has more in common with an automatically created unique ID used as a primary key than with a pointer. <p>Since your premise is false, the rest of your argument is moot. <br> <blockquote TYPE=CITE>> - it *must* never change throughout the lifetime of an object. <p>How does it achieve this when I embed the object in my Excel spreadsheet, <br>print out the spreadsheet and fax it to someone else?</blockquote> <p><br>You cannot embed the object in your spreadsheet. OO 101: Objects have identity. You may copy values to your spreadsheet, you may include the reference to the object in your spreadsheet (if it supports that) so it can dynamically update the spreadsheet as the object state changes, but if the object is *in* the spreadsheet, then it is *not in* the DB. <p>Your printout does not *contain* any objects, merely statically captured state rendered in a printed form. The fax is a copy of that. These notions have nothing to do with database management and are red herrings. <p>If the object referred to by your spreadsheet is subsequently deleted from the database, the spreadsheet is no longer valid. Excel already has notions of broken links (ever seen a #REF in a cell?). <br> <blockquote TYPE=CITE>> - it should give you an error if try to access an object, that has been <br>> deleted. <p>As would any dangling pointer, which is just one reason why pointers prove <br>so inflexible and ineffective.</blockquote> <p><br>No, pointers don't know they are dangling which why they are so inflexible and ineffective. <br> <blockquote TYPE=CITE>How exactly does this new reference type differ from the relational method <br>of simply exposing the object directly?</blockquote> <p><br>Exposing the object directly violates encapsulation. It exposes implementation details that are properly abstracted behind the object interface. <p>I don't expect you to agree with me or to see the subtlety of the difference, but it is the answer to your question. <blockquote TYPE=CITE>> The construct of the "reference" brings the task of key-generation to the <br>> DBMS. <p>Unfortunately, it hides the identity of data from the user at the same time. <br>A DBMS can generate unique key values without resorting to pointers.</blockquote> <p><br>DBMS-generated unique key values provide no data identity values to the user either. <br> <blockquote TYPE=CITE>> You can look at a reference and it tells you: who or what it is and <br>> when it is. <p>I sincerely doubt that many human users can tell anything by observing a <br>reference.</blockquote> <p><br>I sincerely doubt that many human users can tell anything by observing a DBMS-generated unique key either. <br> <blockquote TYPE=CITE>> Since my design skills are week ( and I am not an advocat for RDBMS like <br>> they exist now), please show us your simple approach in SQL. <p>Since I am not an advocate of SQL, why should I? If you want to criticize <br>SQL databases for lack of domain support, be my guest. I would encourage <br>you.</blockquote> <p><br>And if you cannot offer any viable alternative, why are you wasting everyone's time? The request for SQL was because that is the lingua franca of RDBMS. There is no other common (ANSI/ISO?) language for interacting with databases, is there? If so, what products support it? <br> <blockquote TYPE=CITE>> There are some situations, where navigation is useful. If the task you have <br>> to perform needs navigation, why should a DBMS (OO or R) hinder you ? <p>No task requires navigation. Why should any dbms require it?</blockquote> <p><br>That is a bold and omniscient claim. How do you propose to support it? How does one prove that the universe of problems may be solved in precisely one way? <br> <blockquote TYPE=CITE>> For example, how do you implement a topological sort with a RDBMS. (Maybe <br>> there is a solution, but why should I hire a relational algebra pro, if the <br>> task is easy with navigation) <p>You do not need an expert on RDBMS to implement a topological sort, you need <br>an expert on graph theory.</blockquote> <p><br>Substitute one expert for another and what have you proven? That the task is still outside the reach of the average implementer who needs to solve it? <br> <blockquote TYPE=CITE>> - i am not derived from ClassX, but i can look like and act like ? <p>If you look like and act like, you are derived from, or you are ClassX. <br>Remember physical independence!</blockquote> <p><br>There is a significant difference between "I am of (derived from) Class X" and "I can be converted to Type X (or I play one on TV)". This is well before we get to physical implementation issues. <p><tt>--</tt> <br><tt>Jim Melton, novice guru | So far as we know, our</tt> <br><tt>e-mail: Jim.Melton_at_Technologist.com | computer has never had</tt> <br><tt>v-mail: (303) 971-3846 | an undetected error.</tt></html> --------------1AF4C94CC8E7CFBB7C79F545-- --------------7739D021F8709831A5532A44 Content-Type: text/x-vcard; charset=us-ascii; name="Jim.Melton.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Jim Melton Content-Disposition: attachment; filename="Jim.Melton.vcf" begin:vcard n:Melton;Jim x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:Jim.Melton_at_Technologist.com x-mozilla-cpt:;1 fn:Jim Melton end:vcard --------------7739D021F8709831A5532A44--