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