Scott David Daniels <[EMAIL PROTECTED]> wrote: > Mike Meyer wrote: > > Benji York <[EMAIL PROTECTED]> writes: > >> 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. > > 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. Picking ONE database engine may well be premature nevertheless -- perhaps the small amounts of data you have today make SQLite ideal, but tomorrow there will be many more data, and you'll want PostgreSQL, or whatever; which is why maintaining portability among different databases may well be a great choice, even when it requires the overhead of a "database independence layer". But being able to rely on a relational underlying model remains an excellent idea in many cases, even when minute details of SQL dialects &c require such a layer... Alex -- http://mail.python.org/mailman/listinfo/python-list
