Database options was (Re: My first Magma experience ...)
Cees de Groot
cg at cdegroot.com
Mon Apr 4 11:46:49 UTC 2005
On Sun, 03 Apr 2005 20:55:40 +0200, Marten Feldtmann
<m.feldtmann at t-online.de> wrote:
> 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.
Not true. If anything, Smalltalk has too many frameworks :). I think stuff
like Glorp (which is lacking some management tools but in essence is very
very good) is just fine.
However, us Smalltalkers are hurt more by the inflexibility that an O/R
mapping layer inevitably introduces into the software. If you are
programming in Java, you don't expect flexibility, so the O/R mapping
layer is just another items on the long, long, long list of things that
all conspire to put you into a straightjacket. You simply don't notice.
In Smalltalk, you race off with 'in image' persistency, are slowed down
only a tiny bit when moving that to an OODBMS, but then introducing an O/R
layer is like putting on the handbrake. That gets people whining...
> 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.
>
Yup. Seen it, been there, loads of t-shirts. Several very large customers
of mine all had the same strategy: we don't care what you use to develop,
as long as the data lands in Oracle and you comment/document all the
tables and all the columns. Of course, this sucks for an OO guy who likes
to work with an OODBMS, but if I were the IT director of such a shop, I'd
do exactly the same thing.
Maybe one solution would be to develop and unit test in a full OO
environment, and then do a sort of 'compilation' to an RDBMS just before
acceptance testing&shipping...
Or pray that the holy grail of a services infrastructure will work to
lessen these requirements for lots of customers...
More information about the Squeak-dev
mailing list
|