Re: [Pharo-project] databases
Hello Laurent, I assume you are aware of: http://www.seaside.st/documentation/persistence Stephan
No :) Thanks for the link ! Laurent Laffont On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont <stephan@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
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. 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@gmail.com>wrote:
No :) Thanks for the link !
Laurent Laffont
On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont <stephan@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
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 comment: "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 completely different." what do you think about it? maybe you can include something of that. 2010/2/17 laurent laffont <laurent.laffont@gmail.com>
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. 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@gmail.com> wrote:
No :) Thanks for the link !
Laurent Laffont
On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont <stephan@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
On 2/17/10 9:44 AM, Gabriel Brunstein wrote:
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 comment:
"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 completely different."
what do you think about it? maybe you can include something of that. I'm using Magma on a project where there is a central server running Seaside & Magma that is the "master" application. There are also a few users who have a one-click Seaside & Magma image running on their local machines that launches Mozilla Prism to the local Seaside using OSProcess. I'm using Magma to maintain a local read-only copy of the master that can catch itself up when online. I'm also using Gjaller-like transactions that are generated against the domain model, and later sent to the master server to be "applied" when the user comes online again. I considered using Gemstone, but the problem with Gemstone for this particular case is its "server-ness". It runs a few different processes that all do different things (the DB, the memory caches, VMs, etc.). So in my situation I couldn't have a nice "one-click" setup that could be deployed on client machines that could also handle being disconnected from the "master" database.
2010/2/17 laurent laffont <laurent.laffont@gmail.com <mailto:laurent.laffont@gmail.com>>
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. 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@gmail.com <mailto:laurent.laffont@gmail.com>> wrote:
No :) Thanks for the link !
Laurent Laffont
On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont <stephan@stack.nl <mailto:stephan@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 <mailto: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 <mailto: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
-- Dave Woodward ................................................... www.promedmedical.net 317.332.6438 davewoodward@promedmedical.net
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). 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. 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@gmail.com>wrote:
No :) Thanks for the link !
Laurent Laffont
On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont <stephan@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
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@gmail.com>wrote:
No :) Thanks for the link !
Laurent Laffont
On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont <stephan@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
Em 18/02/2010 13:51, Levente Uzonyi < leves@elte.hu > escreveu:
On Wed, 17 Feb 2010, laurent laffont wrote:
[snipped]
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). 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.
Levente, I think the advice doesn't intend to imply that RDBMSs are legacy _technology_. What I understand from the text is understanding the existence of an application (or a lot of data) already using a RDBMS, and so it is legacy for the programmer with the task at hand. OTOH, if we take the features of the RDBMS is central to task at hand, (and not available to Pharo) or ORM makes performance unacceptable then it may end that Pharo should not contemplated to start with, so the point becomes moot. . . just my 0.019999.... -- Cesar Rabak
participants (7)
-
csrabak＠bol.com.br -
Dave Woodward -
Gabriel Brunstein -
laurent laffont -
Levente Uzonyi -
Miguel Enrique Cobá Martinez -
Stephan Eggermont