[DISCUSSION] Object Relational Mapping (ORM) for different programming languages

[Thorsten Hohage]

Hi,

On 2007-10-10, at 22:54, Philip Mötteli wrote:
> (Disclaimer: I don't know Ruby and I don't know RealBasic either.)
Ruby is really worth to get known by everyone who loves a esthetic OO  
style ;-) - but when you really think and love "oo" and already used  
to work with frameworks (and this is the case when you use Obj-C????)  
then Ruby will be a weekend to get it. When you already know  
WebObjects then even RubyOnRails will be only a few days more.


> Actually, as far as I understand it, Valentina is much better than  
> this approach. As I understand it, this ActiveRecord library has to  
> create a foreign key at the other side.
YES (and already written in my previous mail, a good suggestion is to  
even use the standard name for this)


> With Valentina, we can just use OID and it's done. Especially, we  
> have the huge advantage, that this OID can point to any table.
Yes.


"small" BUT: a lot of definition is in good design(! - ?!?!) done  
with abstract classes(tables). So you start with a abstract  
"SuperERP" and "SuperPosition". Now you define a link between  
SuperERP and SuperPosition and a lot of logic / methods / properties  
are defined in this superclasses.

Then you can inherit (or in my framework "virtual" inherit) form this  
classes "Invoice", "Offer", ... and "InvoivePosition",  
"OfferPosition". In some application I go a step further and define  
"roomInvoicePosition", "serviceInvoicePosition",  
"restaurantInvoicePosition" and all are used in the same "Invoice".

How will you model this with Valentina? Of course you can transform  
table inheritance to a "root table" and linked tables. So all columns  
of "SuperPosition" are in the the SuperPositionTable, and only the  
additional columns of "InvoivePosition" are in  
"InvoicePositionTable", ... but then "SuperPositionTable" could  
become really hugh - this maybe handled due to the power of Valentina.

But thinking a step further, and there is a real super object  
"SuperObject" for ALL other classes/tables in my model. Then you  
become the "tower of babylon" table of db design ;-)



> For the other part: what is great with dynamic, dynamic (method)  
> binding, is that I can put a fault at the place of the real object
Yes fault are great and really necessary to create fast and lean  
applications. Sometimes it's a different story for an application  
server, but for desktop client/server apps they are a MUST.

> (containing only this OID)
and IMHO the "class" but that depends on the style of implementation


> and when this fault receives any message, the fault replaces itself  
> with the real object, by loading the data from the db,
And this results in many, many small select statements instead of  
hugh cursors. Luckily after several discussions Paradigma optimized  
Valentina for this usage, too. I'm not able (especially at this time)  
to remember the factor, but the difference between unoptimized 2.x  
Valentina and highly optimized Valentina 3.x was unbelievable (THIS  
WAS A REAL GOOD JOB, RUSLAN! THANKS!)


> and then forwarding the original message to the real object. We  
> say, that the fault has fired.
And in the other way, faults are a good way to do cache management  
without headache. Because you can throw the data over the board, but  
keep it as a fault.


> I don't even need a common superclass, like this ActiveRecord.
But then you need some interfaces to implement in each class, or  
other advanced OO-patterns to do it. I prefer having a SuperClass,  
but this may be related to REALbasic and its style of OO. This could  
be a different story when using Obj-C.



regards

Thorsten Hohage
--
objectmanufactur.com - Hamburg,Germany