Re: Possible bridges between OO programming proponents and relational model

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...

.