gaboto at gmail.com
Wed Feb 17 09:44:52 EST 2010
I didn´t know the advantages and disadvantages of Gemstone over Magma, I've
found http://gemstonesoup.wordpress.com/2009/03/09/why-glass/ with this
"Denis, the most obvious difference is that magma is used from a smalltalk
image (squeak, pharo,…) as a database add-on. Gemstone _is_ the database and
the image you run.
In gemstone even the system classes are in the image that are persistent.
Some parts of gemstone oodb are built in a native language. They are
optimized in more traditional way for the speed of objects acquiry. Magma is
done in pure smalltalk and should therefor be really flexible in what you
can do with it.
>From the programming side they aren’t that different. You build your object
graph in both and you need to attach this graph somewhere that it doesn’t
get garbage collected. In Magma you have one database root where you attach
your stuff. In Gemstone you can attach things just everywhere because
everything is part of the persistent things.
I don’t know both that well. But Magma you can download and there you go. It
is just a piece of software you load and you have a OO persistence layer.
This is very good for deploying along with an image. I never tested to use
magma as a server. Lately magma came up with some cool features like
distributed databases, offline objects and high availability. I like to do
some stuff with it.
On the other hand gemstone you must deploy in more server like environment.
It eats a certain amount of your memory. But you get a server that performs
really well, has proven scalability, cares more about security and user
based data separation. It is something fast and solid for me. With the
remote debugging features it is the ideal database for my purposes so that
were the reasons to choose it.
I hope this helps you little bit in understanding. Magma and gemstone are in
principal the same: they are OODBS. But for me the usage scenarios are
what do you think about it? maybe you can include something of that.
2010/2/17 laurent laffont <laurent.laffont at gmail.com>
> Really great informations :
> 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
> 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.
> 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:
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev