Re: Possible bridges between OO programming proponents and relational model
Date: 5 Jun 2006 03:46:29 -0700
J M Davitt wrote:
> Cimode wrote:
> > J M Davitt wrote:
> >>Cimode wrote:
> >>><<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?
> >>Clarification please: are you saying that direct image implementations
> >>are two dimensional because all the columns are adjacent to each other
> >>in a row? (If so, you're writing a very different language than the
> >>readers of your posts are reading.)
> > <<Clarification please: are you saying that direct image
> > implementations
> > are two dimensional because all the columns are adjacent to each other
> > in a row? (If so, you're writing a very different language than the
> > readers of your posts are reading.) >>
> > Not only and the fact that they are adjacent is not really the issue
> > but this description seems closer to what I mean. Thank you very much
> > for helping a better formulation of the issue. (I may have troubles
> > expressing the concept). This thread seems to be taking off after all.
> > What is your insight on that.? Can OO in-memory mechanisms be helpful
> > on that matter? Most people here seem to believe the opposite.
> A couple points: although many SQL implementations are direct image -
> meaning that rows are stored as rows and tables are stored as tables -
> not all of them are. In other words, there are implementations where
> a table's rows and a row's columns are "spread out all over the place."
> This has nothing to do with either the relational model or SQL.
Yes the sense that it does not redefine the logical model but imposes a serious limitation on separating logical from physical.
> As for "OO in-memory mechanisms," I think that such storage schemes
> should be described a one-dimensional, don't you?.
Yes but most adresses are relative not absolute which makes it necessary to range them in (Row/Column or Block) types of addressing scheme. Which make the implementations bidimensional or tridimensional.
After all, each
> instance is allocated a bunch of bits from a linear address space.
> Just because it's apparently a simple matter to pass an address
> around doesn't mean that the content of all addresses are easily
> accessed. MIPS chips and Intel chips have very different techniques
> for managing large memory fields. But that fact doesn't have anything
> to do with OO concepts, does it? Well, neither does the choice of
> storage technique have anything to do with relational concepts or SQL.
Not just storage but also the way operations are performed. Received on Mon Jun 05 2006 - 12:46:29 CEST