Re: GDL2/EOF scaling (was: Re: GNUstep roadmap)

[Marco Scheurer]

Like many other things there are engineering trade-offs when using 
something like EOF.

On one hand it is of course very nice to be able to use OOP on database 
records. We put a *lot* of logic in the (eo)model. We've been using EOF 
on databases with >100k records, but always so that only a subset of 
the data was accessed by the user.

On the other hand, it is true that EOF doesn't scale well. This means 
that you have to give up the flexibility of the object model and all 
your business logic when you need to do "batch processing" (and decide 
when to do so). Tricks like having several entities mapped on the same 
table (for intance a light object for list display, and a full one for 
inspection/edition) are hard to make work well in practice.

On smaller projects, I agree with Helge that alternatives to relational 
databases could be used (even when we often stick with EOF and 
FrontBase or PostgreSQL because customers sometimes specifically ask 
for a relational database). On larger projects, maybe unfortunately, 
object databases have not caught on.

marco

Marco Scheurer
Sen:te, Lausanne, Switzerland    http://www.sente.ch