[Pharo-project] databases

Miguel Enrique Cobá Martinez miguel.coba at gmail.com
Thu Feb 18 11:31:43 EST 2010


El jue, 18-02-2010 a las 16:51 +0100, Levente Uzonyi escribió:
> On Wed, 17 Feb 2010, laurent laffont wrote:
> 
> > Really great informations :
> > Scenario˙˙s
> >
> > In different situations, there are different storage needs
> >
> >   1. You are writing a small demonstration program to show your customers,
> >   and want to populate the system with some representative data. Add a class
> >   instance variable to store the instances, and simply save the image.
> >   2. You have a small system with a few hundred/thousand objects, and are
> >   not dependent on external systems. A prevayler-like system like SandstoneDB
> >   might be a perfect fit. Each object save means a disk access, so scaling
> >   ends with disk speed. A few old versions of the data are kept around, so
> >   backing up or reverting is easy. If you want a readable representation, SIXX
> >   might help.
> >   3. You have a legacy (relational) database, with extensive reporting
> >   written for it. Use an ORM.
> 
> Relational databases are not legacy, they have features which "modern" 
> key-value stores don't (and won't).


I don't think he is refering to RDBMS as legacy, as we know that they
aren't. I think that he meant that when you have a fully populated
database (legacy) and you are building a new seaside/pharo application
to exploit that data, the best is to use an ORM for simple querys and
direct querys for complex ones.

>  ORMs may ease the programmer's work, 
> but they tend to have bad runtime performance and can't use (all) the 
> features of todays RDBMSs.

That is true but also the right thing, it isn't expected that an ORM
standardize a way to backup a database, partition a table, replication,
node management, user sessions and transaction monitoring, change index
types and in general everything that is considered metadata or simply
database administration.
An ORM is for user stuff querys, insertions, deletion, etc.

Cheers
> 
> 
> Levente
> 
> >   4. You have a complex and large object model that has to support changing
> >   the object model while developing. The solution is an OODB. Gemstone is the
> >   large and proven commercial offering. It has a free version for smaller
> >   databases (4GB data, 1 core, 1G ram), and has proven scalability to 500
> >   machines. Magma is an open source OODB, seeing active development and
> >   growing more and more advanced functionality.
> >
> >
> >
> > Laurent Laffont
> >
> >
> > On Wed, Feb 17, 2010 at 3:07 PM, laurent laffont
> > <laurent.laffont at gmail.com>wrote:
> >
> >> No :)  Thanks for the link !
> >>
> >> Laurent Laffont
> >>
> >>
> >>
> >> On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont <stephan at stack.nl>wrote:
> >>
> >>> Hello Laurent,
> >>>
> >>> I assume you are aware of:
> >>>
> >>> http://www.seaside.st/documentation/persistence
> >>>
> >>> Stephan
> >>>
> >>> _______________________________________________
> >>> Pharo-project mailing list
> >>> Pharo-project at lists.gforge.inria.fr
> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>>
> >>
> >>
> >
> _______________________________________________ Pharo-project mailing list Pharo-project at lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- 
Miguel Cobá
http://miguel.leugim.com.mx





More information about the Pharo-dev mailing list