On Jan 2, 2007, at 11:10 , J J 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?
Handling large amounts of enterprise data. If you have never worked in a large company, you probably wont appreciate this.
Well, I have worked in a large-ish enterprise and my experience was that moving *away* from the RDB was central to improving performance around a hundred- to a thousandfold, with the bigger improvement for the project that completely eliminated the RDB.
But in a large company you have a *lot* of data, and different applications want to see different parts of it. In an RDBMS this is no problem, you normalize the data and take one of a few strategies to supply it to the different consumers (e.g. views, stored procedures, etc.).
Har har. Sorry, but I have seen very few actually reusable data models.
- 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?
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.
You are kidding, right?
The DBA's can watch how the database is being used and tune this (i.e. partition the data and move it to another CPU, etc., etc.).
To some limited extent, yes. But they can't work miracles, and neither can the DB. In fact, if you know your access patterns, you can (almost) always do better than the DB, simply because there are fewer layers between you and the code.
Oh, but you found one example where someone with a lot of data didn't use a RDB. I guess we can throw the whole technology sector in the trash. Sanity check: google is trying to keep a current snapshot of all websites and run it on commodity hardware. You could do exactly the same thing with a lot less CPU's using a highly tuned, distributed RDBMS.
That's a big claim, mister. Care to back it up?
Marcel