> - in OODBs this case is easy. The serialization contains everything
> from the key-values and the class that they belong to. Sometimes the
> data format on disk is the same as in memory so there is less to
> do. The difference between magma and gemstone is that magma is an
> addition to an image. That means you have your smalltalk image in
> memory and than you have magma. With magma you define a persisted root
> object, e.g. a Dictionary. Everything you attach to the Dictionary
> will be persisted if you do a commit. Well, you need to do your
> changes inside a transaction but there are always ways to make this
> look nearly transparent. In gemstone everything is already persisted
> including all the classes and objects. As soon as you attach a newly
> created object somewhere that is already persistent it will be
> persisted, too. The easiest way of handling your data is to keep an
> instance variable in your class that holds the instances. Et voila,
> that's all! All you objects are persisted. Speaking of seaside
> gemstone can be used doing autocommits on a request basis so you don't
> have to care at all about transactions. You just use your objects and
> that is it. Querying is like using collections. If you need special
> kind of querying either for your problem or performance you can
> provide a special type of collection that is optimized for the problem

>
> - In SQL databases the instance variables are mapped to columns of a
> table or multiple tables and each row is an object. Relationships of
> objects are handled by keys in the tables. A 1:1 relationships
> contains a key of the relation source in the relation target table. A
> n:m relationship needs an intermediate table that maps relation source
> keys to relation target keys. Talking about inheritance this gets
> easily complicated. Basically there are two options. You can solve it
> like everyone would expect it, let's say more BNF like. You would have
> a table A for class A and a table B for class B. Now in all tables of
> objects that reference A or B you need an additional information which
> class is meant: A or B. The tables than could be joint correctly after
> evaluation the additional value. Another strategy is to do multiple
> lookups until you've found the right value. The other approach is to
> make one table that is a super set of all needed variables. The keys
> are unique among all the subclasses and can be lookuped up more
> easily. But you waste some space because a lot of the columns would be
> empty. In any case you need to change your database schema if you
> change your model. Joins and number of requests can grow easily so
> that your application will be slowed down. Glorp gives you all of
> these strategies if you want them. My personal advize would be to
> avoid inheritance in that scenario completely or do only the simplest
> cases possible. Relational databases and object oriented approaches
> just don't fit together.