Object-Persistence in database

Ruslan Zasukhin sunshine at public.kherson.ua
Thu Dec 15 14:29:57 CST 2005


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

Hi Philip, 

I split answer into several letters to get several threads about different
issues. 

>> Serialization way * has a lots of problems...IMHO.
> 
> Please explain. 

You see above.
 
>> I have never like ideas of OO DBMS as ODMG describeS. Main reasons:
>> 
>> - IMHO it is bad when user do not see when info go to/from db.
> 
> Well, do you see your computers CPU shifting the registers? Pushing
> an electron from one transistor to an other?
> Software engineering is not about rewriting everything yourself.
> That's the very reason, why OOP has been invented.

Right, but read below.

>> - IMHO payment for such feature is unneeded overhead to watch for  objects,
>> to load them and unload them, a lots of proxy-objects...
> 
> This payment is small:
> 
> - Load: A fault fires.
> - Unload: An object is just freed in memory, like any other object.

I believe it is not so small. It easy can overload time of db operations
itself.    
 
> Of course, the more features you want, the more expensive it gets: If
> you want a realtime image of your persistent objects on the DBMS, you
> need something that observes those objects for mutations (Bindings/
> isa-swizzling/Proxies would be the way to go.) But I'd say, you pay
> the same price with your method.

>> nightmare.
> 
> :-) Just once: The one who implements the persistence library. For
> the millions of programmers, that gonna use that library, it is a
> benediction.

And here let me catch you.

MILLIONS of programmers DO NOT use this attempts to make such layers.
MILLONS do use RDBMS...Very few try play with OO DBMS.

So I do not see in real life prove of your words, that it is so cool.

BTW, this way is not so cool, at least because it will lack SQL power.
And this way require low-level programming which have kill in the past
network and hierarchical models and win Relational.

This is what I see in reality.
 
Yes, I understand your point perfectly.
    WE ALL DREAM write code as small as possible to solve task.

Yes, we see that power of computer grow, so soon house-wifes will develop
software suing bubble-sort and be happy :-)

-----------------
Seriously. 

I still believe that such layer can be used only for something simple. But I
do not think it is good idea choose it for db with 50 tables, 100 relations
millions records.. 

Okay, it may be will work, but normal solution on relational or OR model
will work 10-20-how many times faster?

Okay, having such layer developer produce model using own C++/Java/ObjC
classes, right ?

In other words, his db is CLOSED for use in other language, PHP for example?
With other application? Report righter for example?

May be I do not understand yet something ...
I will think.

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




More information about the Valentina-beta mailing list