Benji York <[EMAIL PROTECTED]> writes:
> Russell E. Owen wrote:
>> I disagree. Once you've picked a database (not trivial in itself, of
>> course), you typically only have a few options for talking to in in
>> Python.
> Perhaps it's off-topic for this thread, but I think "picking a
> database" is the first mistake most people make. It's a form of
> premature optimization.
For lots of problems, that's true. But not for all of them.
> Just like any other component in a system, develop your app without a
> database until you see that you need one, don't just assume you do
> from the beginning.
What makes me think "I need a database" is a requirement that says
"multiple simultaneous writers". Yes, it's possible to deal with the
data locking and the like on your own - but this tends to be
system-dependent, and hard to get right except in the simple
cases. It's also one of the things that databases are *really* good
at. In this case, using a database isn't a performance optimization,
it's a code simplification optimization, sort of like using
Queue.Queue to do threading.
> That's also why I don't see much point to the
> relational-database-centric web frameworks that are all the rage
> today, but I'll save that rant for another day.
If your web clients can write data, then you've got multiple
simultaneous writers - which means you probably want a database. Of
course, people like to build web apps that don't write data on top of
relational databases, which I think are well deserving of your rant.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
