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
|