relational for what? [was: Design Principles Behind Smalltalk, Revisited]

Marcel Weiher marcel at metaobject.com
Thu Jan 4 04:41:58 UTC 2007


On Jan 3, 2007, at 13:01 , J J wrote:
[I wrote]
>> You are kidding, right?
>
> Who are you people getting for DBA's? :)

Let's pull back some context here:


>> Are you serious with this (data too large to fit into memory)?  And  
>> if you use a good RDBMS then you don't have to worry about disk  
>> speed or distribution.

Do you really, truly believe you don't have to worry about physical  
parameters such as disk speed just because there is an intermediate  
layer between you and your disk(s) called a RDBMS?

Then our vendor must have been really ignorant when they recommended  
that we get faster machines with faster disks in order to fix problems  
we were having where the database could not keep up with the (write)  
data rate.  And reality must also have not known about this magical  
property of RDBMS to make you immune to physical limtations, because  
getting faster disks *did* actually solve the problem.

Or are you saying that what happens is that you pay someone else to  
worry about those parameters?

Of course, using a database in that scenario was actually not  
necessary, and the benefits that the vendor touted for their database- 
based system were quite irrelevant in our application context.  We  
could have built a far (a) faster (b) simpler (c) more reliable and  
(d) cheaper system had we not bought into the "must use RDBMS because  
it makes everything better" voodoo and just kept the relevant data in  
application memory.  This might have been a small amount of extra  
programming initially, but would it ever have paid off in maintenance.

Especially since we didn't actually own the data, we were just getting  
a feed from somewhere else.

Had the data been ours, that would have been a different story,  
because data-integrity is one RDBMS myth that I still believe in, as  
it hasn't been beaten out of me yet by encounters with reality...

Marcel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070103/346d629d/attachment.htm


More information about the Squeak-dev mailing list