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.laff...@gmail.com>wrote: > > > >> No :) Thanks for the link ! > >> > >> Laurent Laffont > >> > >> > >> > >> On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont <step...@stack.nl>wrote: > >> > >>> Hello Laurent, > >>> > >>> I assume you are aware of: > >>> > >>> http://www.seaside.st/documentation/persistence > >>> > >>> Stephan > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project@lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> > > > _______________________________________________ Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
