Database options was (Re: My first Magma experience ...)

Trygve Reenskaug trygver at ifi.uio.no
Mon Apr 4 09:50:41 UTC 2005


What to me is the most important consideration is that user data is much 
more valuable than application programs. User data MUST survive new 
versions of the applications and MUST survive refactorings and other class 
changes. This is particularly important if there are many 
clients/installations so that "big bang" database conversion is impracticable.

It is, therefore, crucial that there is a mapping layer between the 
persistent data and the program classes. In one application I have running 
on my current desktop, every persistent data record has its own version 
number.  For example, class Text recognizes seven different formats for the 
text record. This reflects that through the years, we have had seven 
different classes for persistent text in this application. The users don't 
care, of course, and need not be aware of the differences.

ODMG (and Magma) seem to block application evolution by storing the binary 
objects so that class definitions can't change. It will be difficult to use 
them in critical applications if this is correct.

Cheers,
--Trygve


At 20:55 03.04.2005, Marten Feldtmann wrote:
>Cees de Groot schrieb:
>
>>On Sat, 02 Apr 2005 23:41:20 -0600, Jimmie Houchin 
>><jhouchin at cableone.net>  wrote:
>>
>>>It seems that for productions sites with larger database needs that
>>>Relational databases are currently preferred. At least this is how I
>>>interpret what I've read. Please feel free to correct.
>>I disagree. I put the cut only w.r.t. the complexity of the domain 
>>model.  Simple domain model -> relational; complex domain model -> OODB. 
>>No matter  what people say, there's a chasm between the OO and relational 
>>models and  it will hurt your ability to create a flexible domain model, 
>>which IMNSHO  is one of the most important things about any moderately 
>>complex app.
>
>
>No question about this but RDBMS offers lots of possible solutions. Go with
>embedded solutions (using SQLite or Firebird), use costless solutions like
>PostgreSQL or Firebird or Ingres for mutli-user solutions and end up with
>global players like SQLServer, DB2, Oracle, Informix.
>
>There's a gap between OO tools and RDBMS - no question about this. Developers
>have to accept this - or go with their own solutions using a very special
>database with all their advantages and disadvantages.
>
>If I hear about solutions for customers based on OODBMS I ask myself, if this
>is a solution which meets the developers need or the customers need. In the
>first step, the customer gets a solution - but it's very often a closed
>application.
>
>Smalltalkers seems to have more problems with that than other developers
>in Java (JDBC) or Delphi or .NET - one of the reason can be, that Smalltalk
>did not have the frameworks one should have, when working with RDBMS. This
>is (in my opinion) true for VW, VA and other Smalltalk systems. Knowing
>this I can understand why Smalltalk system do not like to be compared
>against MS Access, Visual dBase - these so often called less powerful
>solutions can produce applications (reports, data management), which
>meets more the expectations of the customer, than Smalltalk system can
>offer today: problems like reports, automated generated input/output
>forms are not the hot items, the Smalltalk community likes to talk
>about.
>
>The sentence above concerning "larger databases" is sometimes really true.
>In larger companes you very often have special database adminstrators and
>these database administrators are very important in that IT structure.
>
>If you able to offer your solution in his database, then you have a new
>friend - when offering your solution. When offering solutions using
>other global players, he will not be happy - but he will accept this.
>
>Using PostgreSQL (or stuff like this ...) you will get problems - offering
>solutions only based on (more or less closed) OODBMS you might get into
>really trouble ....
>
>GLORP is a nice sunshine in this world, but it's only a start ....
>
>Marten
>


-- 

Trygve Reenskaug      mailto: trygver at ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway





More information about the Squeak-dev mailing list