Re: Possible bridges between OO programming proponents and relational model
Date: 3 Jun 2006 07:53:52 -0700
<<Okay; you're discussing the physical layer here. (Although your parenthetical remark is incorrect; the choice of a particular implementation strategy isn't what determines whether you have independence or not.)>>
You consider relvar and R-Table physical layer? Can't agree with that (must have missed something). Only SQL implementation (storage, operation) are physical layer. Also, while you can logically *conclude* that you do or do not have data independence for a particular physical implementation puts emphasis on implementation layer to satisfy requirements for data independence.
<< No, I don't think that's correct at all. Physical memory is
Please explain your point.
<< Well, I wouldn't do that if I were you. I think your best bet is to study the existing literature on relational implementation. Read ten papers and see if you think OO has something useful to say.>> Thanks for the word of caution.(I appreciate) but I already started doing that. Diversifying sources helps too. ;)
> Cimode wrote:
> > 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).
> Okay; you're discussing the physical layer here. (Although your
> parenthetical remark is incorrect; the choice of a particular
> implementation strategy isn't what determines whether
> you have independence or not.)
> > So I am curious to why, presicely you are
> > saying that a SQL table is multidimensional.
> Whoops! Now you're talking about the logical layer.
> As Bob already said, a relation with N attributes is n-dimensional.
> This is true regardless of whether you implement that relation
> with a row store or a column store or a piggy bank of slips
> of paper. This is by definition.
> > My guess is that you are
> > refering to what SQL should be as opposed as to how it is implemented.
> > On that case, I agree with that statement. On the opposite case
> Not really; the reference is to the logical layer rather than the
> physical layer. There's no "should be" here; that's how it is.
> > 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.
> No, I don't think that's correct at all. Physical memory is
> everything else is a layer on top of that.
> > 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.
> Well, I wouldn't do that if I were you. I think your best bet is to
> study the existing literature on relational implementation.
> Read ten papers and see if you think OO has something
> useful to say.
Received on Sat Jun 03 2006 - 16:53:52 CEST