Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Possible bridges between OO programming proponents and relational model

Re: Possible bridges between OO programming proponents and relational model

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 03 Jun 2006 13:23:40 GMT
Message-ID: <w3ggg.16878$A26.391175@ursa-nb00s0.nbnet.nb.ca>


Cimode wrote:

> Thank you for your feedback. I do not believe I am making any
> confusion but I should rephrase otherwise for the sake of clarity.
> (Again English is not my native language so expressing consensual
> terminology in english is difficult to me. As Fabian PASCAL declared
> "commitment" to precise terminology is crucial into abording relational
> model matters).
>
> First, I make a clear distinction between SQL and its current
> proprietary implementations(DB2, ORACLE, SQL Server...). As you know,
> several features specified in standard (SQL92) have not been
> implemented, creating lots of overhead work at applicative level into
> guaranteing integrity at physical implementation time (ex:create table)
> which makes SQL implementations and therefore SQL DBMS's unefficient.
> Of course, there is no better alternative as SQL based systems are
> still the best we have.

I am not certain I agree with that last sentence. Of the dbmses that have widely or deeply penetrated the market, SQL based systems are the best we have. There may or may not be better alternatives that are relatively unknown.

> Second, I make a clear distinction between SQL tables *as implemented
> currently* and relvars (called also R-tables). On that standpoint, I
> do not see how are current *physical* implementations of SQL are
> multidimensional when all the ones I know (but I only know the main
> exposed above) use direct image storage of tuple physical
> implementation.(totally defeating relational independence between
> logical and physical layer).

That's a different issue. I agree they provide insufficient physical independence. However, that does not change the degree of a table and does not change the fact that the degree is a direct measure of the dimensions.

   So I am curious to why, presicely you are
> saying that a SQL table is multidimensional. My guess is that you are
> refering to what SQL should be as opposed as to how it is implemented.

No, I am referring to both. Consider the following SQL table:

Create table s5 (

	x as integer not null
,	y as integer not null
,	z as integer not null

) primary key (x,y,z);
insert into s5 values(0,0,5);
insert into s5 values(0,0,-5);
insert into s5 values(0,5,0);
insert into s5 values(0,-5,0);
insert into s5 values(5,0,0);
insert into s5 values(-5,0,0);
insert into s5 values(0,3,4);
insert into s5 values(0,3,-4);
insert into s5 values(0,-3,4);
insert into s5 values(0,-3,-4);
insert into s5 values(0,4,3);
insert into s5 values(0,4,-3);
insert into s5 values(0,-4,3);
insert into s5 values(0,-4,-3);
insert into s5 values(3,0,4);
insert into s5 values(3,0,-4);
insert into s5 values(-3,0,4);
insert into s5 values(-3,0,-4);
insert into s5 values(4,0,3);
insert into s5 values(4,0,-3);
insert into s5 values(-4,0,3);
insert into s5 values(-4,0,-3);
insert into s5 values(3,4,0);
insert into s5 values(3,-4,0);
insert into s5 values(-3,4,0);
insert into s5 values(-3,-4,0);
insert into s5 values(4,3,0);
insert into s5 values(4,-3,0);
insert into s5 values(-4,3,0);
insert into s5 values(-4,-3,0);

Regardless of implementation, a sphere of radius 5 has three dimensions as does the set of integral points on a sphere of radius 5. The table s5 above has degree three and three dimensions: x, y and z.

> On that case, I agree with that statement. On the opposite case

Agreeing with something I never said seems pointless.

> Third, the hidden agenda of this thread is to focus discussion on
> in-memory logic projection of relvars assuming total independence
> between disk based storage and representation of R-Tables at runtime.
> As you also know current SQL implementations (and SQL implemented
> tables) are direct projection of physically static (generally
> bidimensional) representation of tuples.

As a matter of fact, I do not know that because it is in fact not true.

   On such perspective, the
> little education I have about OO mechanisms encourages me to seek
> discussion with OO audience to educate myself about possibilities OO
> can offer to drive a better relational implementation.

I think you will find far more fertile ground elsewhere.

> So no. I do not believe what I am writing is nonsense. So I will
> stick to what I have declared previously. Do not hesitate to
> contradict me if you believe I missed some points. Thank you for your
> implication in this thread.

When you write that an SQL table of degree 3 has two dimensions, then what you write is nonsense regardless of your belief.

> Bob Badour wrote:
>

>>Cimode wrote:
>>
>>>One of the main current flaws of current SQL DBMS systems is their
>>>incapability to implement the multidimensionality of relvars.
>>
>>With all due respect, what you wrote is nonsense. An SQL table of degree
>>N (ie. with N columns) has N dimensions.
Received on Sat Jun 03 2006 - 08:23:40 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US