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
An ORM is for user stuff querys, insertions, deletion, etc.
> > 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
More information about the Pharo-dev