On Wed, 11 Oct 2000, Matt Sergeant wrote:
> > I really think that sometimes going for a flat file layout *can* be much
> > more reliable and scalable then RDBMS software. It all really depends on
> > what you plan to do with the data and what you would like to get out of
> > it.
> I think you chose the wrong words there. I think a flat file layout can be
> more performant than an RDBMS, but I don't think its going to be
> more reliable or scalable than an RDBMS. There are far too many locking
> issues and transaction issues necessary for the terms "reliable and
> scalable", unless you're willing to spend a few years re-coding Oracle :-)
I actually think that there are times that can be all three. Notice how
I said there are times it can be all three, it definately isn't the case
all the time. Neither are RDBMS. ;-)
Lots of places use databases for read-only queries. Having a database
that gets lots of similar queries that are read-only makes it an
unnecessary single point of failure. Why not use the local disk and
use rsync to replicate the data around. This way if a machine goes down,
the others still have a full copy of the content and keep on running.
If you have a lot of data that you need to keep in sync and needs constant
updating with a random amount of different queries then you get some real
use out of a RDBMS.
I guess I am just saying that there are a gazillions of ways of doing things,
and each tool has something it is good at. File systems are really good
at serving up read-only content. So why re-invent the wheel? It all really
depends on what content you are dealing with and how you expect to query
it and use it.
There is a reason that table optimisation and tuning databases is such
a sought after skill. Most of these things require different things that
all rely on the type of content and their use. These things need to be
taken in consideration on a case by case basis.
You can do things terribly using Oracle and you can do things well using
Oracle. The same can be said about just about everything. ;-)
--
Sander van Zoest [[EMAIL PROTECTED]]
Covalent Technologies, Inc. http://www.covalent.net/
(415) 536-5218 http://www.vanzoest.com/sander/
