[ORM]: TYPES

[Thorsten Hohage]

Hi,

On 2007-10-12, at 15:31, Ruslan Zasukhin wrote:

> On 11/10/07 2:10 PM, "Thorsten Hohage"  
> <thohage at objectmanufactur.com> wrote:
>
>>> And our benefit is:
>>>     Valentina Class Way try be as close to Valentina engine as
>>> possible.
>>>     We not going help to Oracle developers :-)
>>
>> Direct reply: When I start using Valentina you told to better use  
>> SQL-
>> way and not class way, so I build my Framework around the sql-way. Do
>> you now really mean that using the Class/API way is a good choice?
>
> Trade-off as always. And better for what ?

See my last reply on faults.


> You have told about using of VSERVER.
> Our answer always is:
>     you want VSERVER? So it can be very remote?

Yes I need VServer (90% of usage), but in most cases it is in local  
network.


>     then obviously that MANY small queries will be slower
>     of single BIG query? Right?
But this issues was solve several months ago, I didn't have any speed  
issues with current version of db. Currently it took way longer to  
fill the ListBox in RB (I know worst case sample), then to fetch the  
data from server and transform it in objcets.



> * ORM in contrast try work with Navigational model. Agree?
Yes,

>     you self navigate between objects, loading them when needed.
and yes,

>     but what if millions objects are in game?
>     Load them by inet will be huge overhead.
Let me try to explain the difference I see here.

You can have a book with say 6000 pages and it will be very difficult  
to handle, read and carry around OR you can have 100 paperbacks with  
60 pages, right?

What is the difference? Same number of pages, but in one book all  
together, in the other separated in many books, divided by the them  
(or "context") of the book. If you want some to read about e.g.  
visiting the Black Sea, you didn't need to carry aroung all the pages  
about the North Sea.

So let's look at "common" business applications (e.g. science may be  
completely different). You've several staff memebers working with  
"their" customers, or a small number of calls per day. And each  
customer have his invoices, but this may not be 20000 per year and  
if, they are probably structured.

If I look a several million records, I see in most cases thousands of  
several hundred object sets, instead of the big one. And then it's  
another story again.



> So I have hear about OO DBMS for desktop apps,
>     OR around some DB SERVER which is on localhost
>     or in the intranet. In this way works EOF, yes?
>     EOF is used to access LOCAL DB SERVER to build web site.

Yes.


> In this conditions YES you can use API/Class way and be more  
> effective of
> SQL way. Sometimes up to 20 times!!

Like already written, I'll check it out.


>> My understanding is, that in many cases a good ORM should abstract
>> the application-level from the database-level, so that you're able to
>> switch between databases stressless.
>
> This is not task of DB VENDOR as WE or Oracle is.
>
> This is dream-task of DB DEVELOPERS. :-)

But we're talking about the WHYs and WHATs of ORM and this is the  
reason, I know it's not in the interest of a DB vendor, but we're  
talking here about ORM in first line, didn't we.


> And it is nothing without SQL Standard. As only one DBMS start have  
> own
> features, and you start use them, you have not compatible code.
Of course this is not simple to answer.

There are several ORMs out there, that only use plain, old sql92.  
They argument, that nothing more is needed, because there is so much  
caching, optimizing done in the server and the actual hardware is  
fast enough to be arrogant and ignorant about vendor-specific features.

Other ORMs was/are big enough, that DB vendors or 3rd party starts to  
developed adopted plugins for the ORM to use with a special DB. Then  
changing the db means, changing the plug-in, too AND say some prayer.

OR another story, you start with a bunch of different DB vendors  
usable with your framework and then month by month another DB is  
unusable due to issue in the used environment (e.g. hard crash when  
you fetch more than 10000 records), legal issues (does anybody starts  
open source all his code, due to using a db????) or several other  
reasons. And in one day you look around and see, that there is only  
one good choice left - what are you going to do? Probably using all  
the feature the lasting vendor will offer you ;-)


> Thosten,
uslan (;-) day of the missing R *lol*)


> Why was born idea of OO DBMS?
>
> HISTORY (as I see it :-)
>
> Idea was:
>
>     I am C++/Java developer.
>     I want only make C++ classes.
>     I do not want even think about DBMS structure, else.

But there maybe additional thoughts. I place a full object (class  
instance) in the persistence layer, not only the data and structure.  
I don't need to worry about versioning or updating. When I call  
".mySpecialFuntion1" then every object will do it in a way that  
belongs to the version of data and structure.

OR for some OODBMS you can specify "Update" mechanism and a fetched  
object is updated completely before "delivering" it to the requesting  
code.

Now think of abstraction and inheritance. All my objects have  
".mySpecialFuntion1" and all implement them in a different style. Now  
you do something like

select ..., Me.mySpecialFuntion1(), ... from SuperClass

(ok, this is sql style, and in OODBMS you commonly didn't use sql)  
how would you do this in a classical db? When thinking about "table  
methods" (you "promised" for Valentina 5 *fg*), then it's a step in  
the right direction. At least we need to think about how to implement  
table inheritance in a good way, then.


> As for me this is way into no where.
> Pure OO DBMS developers develop this dbs trying hide DB behind c++  
> code. And
> I can image how NOT EFFECTIVE solutions are.

Call me the "nowhere man". The problem here, but it's the same in  
many other scenarios is, that some developers start using OODBMS  
without really getting the spirit of what it is. Some try to do an  
"old style db" design, some start coding even without a design, ...  
but this is not the fault of the vendor or the technical concept.

Then there are several project where "management" decided to use  
OODBMS, but the requirement was a pure "raw data machine".


> I have hear few developers that
> have try develop big projects in OO DBMS
I know of several real world apps running really fine and NOT being  
embedded solutions.  One of the examples is a PPS for a manufacturer  
from the automotive/car are, who is also integrating all the machine  
controlling in this workflow. Of course there are million of records,  
but do you remember my "paperbacks"? This requirement was the exact  
real world sample of such a data structure.


> Later vendors of RDBMS also did want add OO features to own  
> products to look
> MODERN.
>
> So they have start develop Object-Relational way.
I stumbled over the name "Object-Relational way". Several DB vendors  
starts integration of (in most cases) Java classes as a column type  
and e.g. Java stored methods. But this was slow and (in a translation  
of a german phrase) "nothing - not fish, not beef".

While real OODBMS are nice to use for a real OO guy (oh and girl, of  
course), these technics are only a sprag for marketing.



> And third wave -- third party vendors which are not DB VENDROS at  
> all, have
> start develop different Wrappers/Frameworks around RDBMS
>
> Right?
>
> So this Framework developers need fight with problems of RDBMS model,
> implement some algorithm on client-side code.
Right.



> So ORM and OO developers want give to developer way to work with
>     PROGRAMMING LANGUAGE Objects that are stored to disk
>         more or less transparently.

Yes, but I think there are some more aspects.


> Valentina Class way offer little less idea.
>     You have tables and field and links as OO CLASES of a Language.
>     But
>         * you have Current record in table.
>         * you work with SETs of records in this or that table.
>         * you navigate between them.
>
> So as for my favor -- it is gold middle between old relational way,  
> and OO
> way with not visible db.
Sounds good, yes and again I'm going to check it.


regards

Thorsten Hohage
--
objectmanufactur.com - Hamburg,Germany