Re: Possible bridges between OO programming proponents and relational model

From: Cimode <cimode_at_hotmail.com>
Date: 2 Jun 2006 12:49:29 -0700
Message-ID: <1149277769.209188.18870_at_j55g2000cwa.googlegroups.com>


One of the main current flaws of current SQL DBMS systems is their incapability to implement the multidimensionality of relvars. The main reason seems to be the lack of independence between the physical layer and logical layer the represent the data. In several DBMS tuples are right away on disk projections imposing that all tables are considered bidimensional. In fact, it should not be the case because a bidimensional RTable is only a *representation* of some entity. An interesting analogy that may help communication, is Rubi's Cube (3 dimensional): looking at one face of the cube it's only one possible representation of the cube (being the relvar)...Thank you for bringing some insight (flamers please refrain) onto how OO mechanism may help separate the logical operation (in memory) from physical layer... Subject is launched...

Cimode wrote:
> <<Like what problems? Can you give a few examples?>>
> Sure. I was refering to problems such as data integrity and data
> redundancy which create lots of performance bottlenecks...For instance,
> people allow NULL values into tables which create the need to add
> additional excluding conditions (IS NULL, IS NOT NULL...) into select
> procedures to get correct results in COUNT statements. As a
> consequence, they degrade performance (both response time and
> througput) when they do that...If NULL were not allowed in the first
> place, then these additional conditions would not be used...
>
> <<I said that being able to specify transformations
> > and automations would do the trick.
> There are some exceptions that require hoop-jumping, but they are
> thankfully
> very rare.
> >> Could you give few examples to illustrate what you mean by transformations and automations? and the exceptions you are refering to?
>
> <<I went the other way myself, putting more abilities into the server
> and
> > using less OO, and it has served our company and our customers well>>
> I don't believe we are speaking about the same thing..
> It seems you are refering to centralizing processes into server side
> which is probably more practical in all senses...I was however refering
> to using OO mechanisms and features as a replacement to SQL (as a
> server side language) for data manipulation and definition...
>
> Thanks for your input...
Received on Fri Jun 02 2006 - 21:49:29 CEST

Original text of this message