relational for what? [was: Design Principles Behind Smalltalk,
hstearns at wisc.edu
Tue Jan 2 14:18:24 UTC 2007
J J wrote:
>> ... I simply believe in the right tool for the right job,
> and you can't beat an RDB in it's domain. ...
That's something I've never really understood: what is the domain in
which Relational Databases excel?
- Data too large to fit in memory? Well, most uses today may have been
too large to fit in memory 20 years ago, but aren't today. And even for
really big data sets today, networks are much faster than disk drives,
so a distributed database (e.g., a DHT) will be faster. Sanity check:
Do you think Google uses an RDB for storing indexes and a cache of the WWW?
- Transactional processing with rollback, three-phase commit, etc?
Again, these don't appear to actually be used by the application servers
that get connected to the databases today. And if they were, would this
be a property of relational databases per se? Finally, in world with
great distributed computing power, is centralized transaction processing
really a superior model?
- Set processing? I'm not sure what you mean by set data, JJ. I've seen
set theory taught in a procedural style, a functional style, and in an
object oriented style, but outside of ERP system training classes, I've
never seen it taught in a relational style. I'm not even sure what that
means. (Tables with other than one key, ...) That's not a proof that
relational is worse, but it does suggest to me that the premise is worth
- Working with other applications that are designed to use RDB's? Maybe,
but that's a tautology, no?
I'm under the impression (could be wrong) that RDBMS were created to
solve a particular problem that may or may not have been true at the
time, but which is no longer the situation today. And what are called
RDBMS no longer actually conform to the original problem/solution space
More information about the Squeak-dev