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 - 14:49:29 CDT
