D'Arcy J.M. Cain
darcy at druid.net
Sun Mar 14 15:48:10 CET 2010
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.
> 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
> 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.
More information about the Python-list