Alex Martelli wrote:
> Scott David Daniels <[EMAIL PROTECTED]> wrote:
>> If the data you store and update is sufficiently valuable to your
>> enterprise, picking a database may be vital.  Transactions guarantee
>> every update either happens or not, and infrastructure is provided
>> for you to be able to backup and restore the data you've obtained.
> 
> A good point, but there are others.  If the data is valuable, there WILL
> be requests from parts of the enterprise to use that data in other ways
> that were originally not anticipated.  If you keep the data in a
> relational DB with any kind of sensible schema, then the data IS
> reusable, including in impromptu exploratory ways from interactive
> prompts of many kinds -- you don't necessarily need "programmers" to
> enable such reuse.
We are in violent agreement here.  My contention is that you need a
_real_ relational database here, not that you need to pick a vendor.
MySQL vs. Pick vs. ... should be shut out early.  A truly relational DB
has value, picking a particular one early does not.  The attributes I
describe are available from any reputable relational DB vendor, and make
no mistake, PostgreSQL is what I consider a vendor -- a provider of a
fully thought-out and implemented solution.

 > ... maintaining portability among different databases may well be a
 > great choice, even when it requires the overhead of a "database
 > independence layer".
Yup.  I think you should choose a vendor, but not in the sense of buying
lock-in; in the sense of accepting a data model.

--Scott David Daniels
[EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to