On 02/18/2015 04:03 PM, Ben Finney wrote:
Is there anything *good* that sits in between the two extremes of
SQLite and PostgreSQL?
What do you need a RDBMS to do, and what do you not need?
The answers to those questions vary hugely between different people (and
most people probably don't think too deeply about them). They will
determine what “good” means for your case.
Is there nothing that amounts to a 'PostgreSQLite'?
PostgreSQL itself fits that mould quite well; it is quite capable of
serving a small footprint while still offering full concurrency.
I don't know of a free-software concurrent RDBMS which can be considered
lighter than that. (No, MySQL doesn't count; its concurrency is
*unreliable* and it commonly loses data silently. Don't use MySQL.)
But perhaps you don't need concurrency? Only you can tell us.
At this point... I don't think concurrency is going to be a major
requirement for what I have in mind. For one project, only a few people
will be writing to the DB, and only by a stroke of luck would it be at
the same time, and it would be very unlikely that they would be
modifying the same record at the same time due to physical constraints.
For the other... there may be anywhere from 1-10 (maybe more, but
doubtful) entering data (creating new records for competitors, or
entering existing competitors in a tournament). I have a hard time
picturing that few people stressing a modern computer system enough to
where SQLite couldn't keep up (thinking web-based interface using Flask
or something similar). In the latter case, one of the over-arching
priorities is that it be easily distributable, as in that people with
relatively little knowledge of a database be able to set it up and run it.
--
Shiny! Let's be bad guys.
Reach me @ memilanuk (at) gmail dot com
--
https://mail.python.org/mailman/listinfo/python-list
