Design Principles Behind Smalltalk, Revisited

J J azreal1977 at hotmail.com
Tue Jan 2 10:14:05 UTC 2007


>From: goran at krampe.se
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: Design Principles Behind Smalltalk, Revisited
>Date: Tue, 2 Jan 2007 10:56:23 +0200
>
>I don't have time right now posting in this thread, let me just mention
>that I disagree with JJ :) regarding the arguments for using an RDB
>instead of an ODB. There are of course arguments in both directions -
>depending on context - but IMHO the lifecycle-argument is not as clear
>cut as described.

Well, let me clarify my position a little.  I don't feel that ODB's are 
useless or anything.  Things you see in the Rails demo's should probably 
have been in an ODB (or even just objects, as Ramon's "blog in 15 minutes" 
showed).  I simply believe in the right tool for the right job, and you 
can't beat an RDB in it's domain.

It depends on what you are doing.  Sometimes in a powerful language like 
smalltalk you just keep your data in objects and let image persistence 
handle it.  Sometimes you want a little more so you write the data out to 
files.  Sometimes you want to go even further, and this is when an ODB can 
be a great solution.

But at the enterprise level (i.e. lots of different programs over a large 
organization) I still see RDBMS as the winner.  And the reason I see it this 
way is simply: SQL/RDB can be seen as a DSL system for dealing with set 
data.  There is a tremendous amount of power built into it for this 
particular domain that would be difficult to make more concise in another 
way.  I suppose it is just a question of how comfortable one is with SQL.

_________________________________________________________________
Get FREE Web site and company branded e-mail from Microsoft Office Live 
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/




More information about the Squeak-dev mailing list