NoSQL Movement?

[D'Arcy J.M. Cain]

On Sun, 14 Mar 2010 10:16:43 -0400
Steve Holden <steve at holdenweb.com> wrote:
> A common complaint about large database loads taking a long time comes
> about because of trying to commit the whole change as a single
> transaction. Such an approach can indeed causes stresses on the database
> system, but aren't usually necessary.

True.

> I don't know about PostgreSQL's capabilities in this area but I do know
> that Oracle (which claims to be all about performance, though in fact I
> believe PostgreSQL is its equal in many applications) allows you to
> switch off the various time-consuming features such as transaction
> logging in order to make bulk updates faster.

Yes, PostgreSQL has a bulk loading option as well.  It's usually useful
when you are copying data from one database into another and need to do
it quickly.

> I also question how many databases would actually find a need to store
> addresses for a sixth of the world's population, but this objection is
> made mostly for comic relief: I understand that tables of such a size
> are necessary sometimes.

How about Microsoft storing it's user base?  Oh wait, they only store
registered users with legitimate copies.  Never mind.

> Of course if you only need sequential access to the data then the
> relational approach may be overkill. I would never argue that relational
> is the best approach for all data and all applications, but it's often
> better than its less-informed critics realize.

As a rule I find that in the real world the larger the dataset the
more likely you need a proper database.  For smaller datasets it
doesn't matter so why not use a DB anyway and be prepared when that
"throwaway" system suddenly becomes your company's core application.

-- 
D'Arcy J.M. Cain <darcy at druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.