Object-Persistence in database

[Ruslan Zasukhin]

On 12/15/05 1:03 PM, "Philip Mötteli" <philip.moetteli at econophone.ch> wrote:

>> Well, INSTEAD, in Valentina we offer other way -- Class way.
>>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> You develop own set of classes (yes which play as persistent),
>> Which are subclasses from Valentina classes. Now you get best of 2
>> worlds.
>>     - you work with OO classes and OO API
> 
> What, if my class already has to inherit from another class, which in
> turn, of course doesn't inherit from a Valentina class?

> Lets say, I  have to reuse a framework for modeling street traffic. There's a
> class "Car". Of course, this framework never heard of Valentina.  Ouhps, now I
> can't save any object from that framework, nor any  subclass I made.

Wrong, Phillip! 

Remember movie "Matrix"?  There is no spoon!

Do you want to say that using RDBMS you cannot solve this task???
Of course you can.

--------
In Valentina I think you can do something as:

Class tblCar : public VTable
{
    public:

        AddCar( Car* inCar )
        {
            mfCarMark = inCar->getMark();
            mfCarColor = inCar->getColor();
            
            AddRecord();
        }
        
    protected:

        VString     mfCarMark;
        VString     mfCarColor;
        ..
}

So I CAN save objects from your framework using

        mTblCar.AddCar( pFrameworkObject )


> Or I have a garage, that contains cars, bicycles and trucks. How do
> you define the relationships in the tables? (It's possible, I know,
> but annoying.)

Right, this is why Valentina introduce links, they reduce work of developer
and are more effective.

> The problem in your example here is, that the relationship of a
> subclass to its superclass is of the kind "is a". It's a refinement
> of the functionality of its superclass.

> A car _is_a_ vehicle and not  a persistent_object. So if I make a subclass of
> a persistent_class,  this subclass should refine this functionality of
> persistency, e. g.  Valentina_persistent_class. Yes, this makes no sense (at
> least, if I  don't explain some more things). That's the reason, why we say,
> that  persistency is just an aspect of a program. Hence the invention of
> Aspect Oriented Programming.

Ok, good point. 

You talk like an academy teacher. Aren't you?  :-)

But who have told you that developer MUST to work with C++ objects AS IS.

When I want find Cars, I do QUERY to table, and I get Cursor as result.
OR I get set of found records if go by non-SQL way.

Okay, I think you want say me:

* development of C++ classes is simpler than development of Relational
tables...
        
   Me: really? Hard to say...and main -- you loose portability of db.

* establishing links in relational model are annoying..

   Me: right. This is why we develop in Valentina NEW model.
    - we have links.
    - soon we will introduce links with order -- similar to
        Collections of ODMG and OO DBMS.

   Me: This is why, I say that Valentina is much more ready
        for any OO layer than ANY normal RDBMS. For example we already
        have OID field, as ODMG require. And our implementation of OID
        eat ZERO bytes on disk, but OO DBMS eat for million records
        8 * 1M = 8 MB plus size of index that can reach 12MB.

            ZERO against 20MB. Not bad?


-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]