On Sun, 14 Mar 2010 10:16:43 -0400 Steve Holden <st...@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 <da...@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. -- http://mail.python.org/mailman/listinfo/python-list
