relational for what? [was: Design Principles Behind Smalltalk,
tblanchard at mac.com
Tue Jan 2 15:17:12 UTC 2007
Funny, I just blogged about this.
On Jan 2, 2007, at 6:18 AM, Howard Stearns wrote:
> 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 questioning.
> - 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 anyway.
More information about the Squeak-dev