Re: Possible bridges between OO programming proponents and relational model

<<I am not certain I agree with that last sentence.>>Can you ellaborate on that? What
do you have in mind?

<<That's a different issue.>>You really think so? I would argue that it is too closely related to to be ignored.

<<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.>> Yes. So. I have never denied that. This is why I made a distinction between SQL tables as they are implemented and SQL tables as they should be represented. Do you have any idea onto how an in memory SQL table footprint looks like on current SQL DBMS?

<<No, I am referring to both. Consider the following SQL table:>> I do have the impression we are talking of different things. I do not disagree with anything you have declared but you totally miss the point I tried explaining several times .

If you consider that SQL tables in traditional DBMS are multidimensional because syntaxically seem to be you are placing yourself exclusively at high level not on in memory level. In which case I understand better the source of confusion.(which is my mistake, I should have been more cautious about that).

<<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.>> Yes. That's not the point.

<<As a matter of fact, I do not know that because it is in fact not true.>>
I don't understand this statement. How can you not know something and disqualify it as not being true. Could you ellaborate?

<<I think you will find far more fertile ground elsewhere.>>Probably. Looking at the spirit of most comments I have read in other threads NG, it seems collaboration is not the main overall drive in this NG. Thank you for pointing it out.

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

I have not written that anywhere (have not used degree). I am curious however as to *what* exactly makes you believe that I said that.

If you don't mind, I will use your example to clarify:

...Consider the following relvar

T5: x,y,z

...then consider its SQL counterpart...

create table s5 (

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

1, 2, 3
3, 5, 5

..considering this output is a direct disk image implementation meaning disk storage mechanism and in-memory representation in current SQL DBMS are *physically* storing

Adress 1/ 1, 2, 3
Adress 2/ 3, 5, 5

I do not understand why you advocate the idea that this particular physical implementation is anything else than bidimensional? (The relvar is not of course). I think I missed something.

Thank you for your valuable insight. Exchanging online is a difficult exercice.

Bob Badour wrote:
> 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 - 16:30:15 CEST