[ALL] let's think about Query Language for 2.0

[Andreas Grosam]

On Freitag, Mai 23, 2003, at 08:32  Uhr, Ruslan Zasukhin wrote:

> on 5/23/03 1:52 PM, Andreas Grosam at agrosam at computerworks.ch wrote:
>
>> However, with respect of querying a database - from the view point of 
>> a
>> user (say a DB App developer) - there are pretty less differences!
>> Consider this:
>> A tuple could also be defined as a set of attributes | value pairs
>> where attribute is of type string and used as the key. This set - a
>> descriptor -  could be referenced by an immutable member of the tuple 
>> -
>> thus defining its number, order and types of the attributes at runtime
>> - but the values can be changed of course.
>> Then, a tuple becomes an object of class Tuple which "type" (a
>> descriptor) will be defined at runtime and a relation is an object of 
>> a
>> class Set<Tuple> containing only those tuples having the same
>> "descriptor".
>> So, it looks like, the relational aspect is just a sub-set of the
>> object-oriented aspect :)
>
> Exactly Andreas !!!!
>
> Look ODMG have go in wrong way.
> I already have told this on this list.
>
> By their way, OO DBMS is totally different from RDBMS.
> But you are right, OO DBMS should be EXACT extension of RDBMS.
Or vice versa - both is possible. (if a tuble is a plain struct - but 
being still an object.)

> Like C++ was extension of C.
>
> I have think about their way to store objects on disk and so on.
> It is LESS effective of RDBMS in general way.
"effective" in what manner? Performance, size, ...?
This depends. It's mainly a matter of implementation. There are DBMS 
which are write optimised (eg. log only) and there are query (read) 
optimised DBMS. Whether they are OO or relational depends on the level 
of implementation above the kernel.
For  instance,  "Monet" is a MainMemory DBMS which vertically 
decomposes the attributes of records or objects. That is, there is a 
file for each attribute of an object or record. This can be read 
sequentially with optimal disk, CPU and Cache utilisation.  Whether 
this is a relational or OO DBMS depends on the level implemented on top 
of the kernel. Since this structure enforces read optimisation and due 
to in memory scanning with mmaped files, this is a very fast query 
machine. OQL and SQL has been implemented on top of it.
OK, the kernel needs information of all the attributes. A pure OO 
approach would not allow that?!

> Their claims that OO DBMS is faster of RDBMs is lie.
> It is faster only for tasks where network model also is faster.
>
Exact. Same thing. However, logical clustering of related objects may 
also lead (sometimes) to better performance. However, this is often 
overestimated. In practice, there is no best clustering nor is there a 
best method for enforcing clustering.

> Next, they have made ODMG only for OO languages like C++, Java, 
> SmallTalk.
> So guys, this is not OO DBMS!!!
> This is simply complex, powerful, implementation of PERSISTANCE for
> instances of this languages.
Yes. Language IS NOT database!
IMO, "persistent objects" is not the same as a DBMS storing objects!

>
> The REALLY OO DBMS should provide all its OO feature (like 
> inheritance),
> Even to procedural languages like Pascal, C, XCMD, Director, PHP.
> And this is target for Valentina.
>
>
> -- 
> Best regards,
> Ruslan Zasukhin      [ I feel the need...the need for speed ]
> -------------------------------------------------------------
> e-mail: ruslan at paradigmasoft.com
> web: http://www.paradigmasoft.com
>
> To subscribe to the Valentina mail list go to:
> http://lists.macserve.net/mailman/listinfo/valentina
> -------------------------------------------------------------
>
> _______________________________________________
> Valentina mailing list
> Valentina at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina
>