<div dir="ltr">I just checked in the Python sources and apparently you're right about SQLite3. The Python distribution includes pysqlite which seems to be a self-contained SQLite engine. No external dependencies. Sorry for the confusion.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-09 9:00 GMT-02:00 Chris Angelico <span dir="ltr"><<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Sun, Feb 9, 2014 at 9:20 PM, Marcel Rodrigues <<a href="mailto:marcelgmr@gmail.com">marcelgmr@gmail.com</a>> wrote:<br>
> As Chris said, if your needs are simple, use SQLite back-end. It's probably<br>
> already installed on your computer and Python has a nice interface to it in<br>
> its standard library.<br>
<br>
</div>Already installed? I thought the point of SQLite3 being in the Python<br>
stdlib was that Python actually included the entire engine (that's why<br>
there's no, for instance, PostgreSQL client in the stdlib - because<br>
there's no server; I disagree with the reasoning, but it is consistent<br>
and valid), so you don't need _anything_ externally installed.<br>
<br>
In any case, SQLite is ideal for really simple databasing. Back in the<br>
1990s, I had DB2, DB2, and DB2, for all my database work. I wanted a<br>
way to query a dictionary of English words using SQL, so I created a<br>
DB2 database and threw ~60K rows into a table. Massive overkill for a<br>
one-column table. These days, I could use SQLite (or more likely, just<br>
use grep on /usr/share/dict/words - grep does everything that I wanted<br>
SQL for, if you include piping from one grep into another), cutting<br>
the overhead down enormously.<br>
<br>
The biggest downside of SQLite3 is concurrency. I haven't dug into the<br>
exact details of the pager system and such, but it seems to be fairly<br>
coarse in its locking. Also, stuff gets a bit complicated when you do<br>
a single transaction involving multiple files. So if you have lots of<br>
processes writing to the same set of SQLite tables, you'll see pretty<br>
poor performance. PostgreSQL handles that situation far better, but<br>
has a lot more overhead, so it's a poor choice for a single simple<br>
application. MySQL's locking/concurrency system is specifically<br>
optimized for a model that's common for web applications: a huge<br>
number of readers and a tiny number of writers (sometimes referred to<br>
as Data Warehousing, because you basically stuff a warehouse full of<br>
data and then everyone comes looking for it). For the write-heavy<br>
model (sometimes called OLTP or On-Line Transaction Processing),<br>
PostgreSQL will hugely outperform MySQL, thanks to its MVCC model.<br>
<br>
Broad recommendation: Single application, tiny workload, concurrency<br>
not an issue, simplicity desired? Go SQLite. Big complex job, need<br>
performance, lots of things reading and writing at once, want<br>
networked access? Go PGSQL. And don't go MySQL if PG is an option.<br>
<br>
And definitely don't go for a non-free option (MS-SQL, DB2, etc)<br>
unless you've looked into it really closely and you are absolutely<br>
thoroughly *sure* that you need that system (which probably means you<br>
need your app to integrate with someone else's, and that other app<br>
demands one particular database).<br>
<br>
ChrisA<br>
<span class="HOEnZb"><font color="#888888">--<br>
<a href="https://mail.python.org/mailman/listinfo/python-list" target="_blank">https://mail.python.org/mailman/listinfo/python-list</a><br>
</font></span></blockquote></div><br></div>