Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Wed, 18 Feb 2015 20:15:30 -0800
From: Ethan Furman <ethan@stoneleaf.us>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: python-list@python.org
Subject: When to use SQLite3 [was Re: 'Lite' Databases (Re: sqlite3 and dates)]
References: <mc1atd$cq0$1@ger.gmane.org> <mailman.18805.1424243139.18130.python-list@python.org> <mc1s1e$feh$1@news.albasani.net> <mailman.18815.1424258499.18130.python-list@python.org> <4154cc37-0bb0-4bf2-a52c-b728c737357c@googlegroups.com> <CAPTjJmogRj_==1wUcLooFwDhUK+saSaAkQEuUo4o30n8aRdB=w@mail.gmail.com> <54E517B4.4000409@stoneleaf.us> <mc37el$ci7$1@ger.gmane.org> <85lhjuahsm.fsf@benfinney.id.au> <mc3li1$ch$1@ger.gmane.org> <CAPTjJmoFnUWb6ZG3RigszFcyeORk9msdjDBR9vO3C=JwtBXK6Q@mail.gmail.com>
In-Reply-To: <CAPTjJmoFnUWb6ZG3RigszFcyeORk9msdjDBR9vO3C=JwtBXK6Q@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eAkWfilHHBdGkaWL6iStq8cn8TLXI1cBf"
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.18853.1424319401.18130.python-list@python.org>
Lines: 88
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:85854

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--eAkWfilHHBdGkaWL6iStq8cn8TLXI1cBf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

At the risk of using actual data, I looked this up at http://www.sqlite.o=
rg/whentouse.html:


Checklist For Choosing The Right Database Engine

 * Is the data separated from the application by a network? =E2=86=92 cho=
ose client/server

    Relational database engines act as a bandwidth-reducing data filter. =
So it is best to keep the database engine and
the data on the same physical device so that the high-bandwidth engine-to=
-disk link does not have to traverse the
network, only the lower-bandwidth application-to-engine link.

    But SQLite is built into the application. So if the data is on a sepa=
rate device from the application, it is
required that the higher bandwidth engine-to-disk link be across the netw=
ork. This works, but it is suboptimal. Hence,
it is usually better to select a client/server database engine when the d=
ata is on a separate device from the application.

 * Many concurrent writers? =E2=86=92 choose client/server

    If many threads and/or processes need to write the database at the sa=
me instant (and they cannot queue up and take
turns) then it is best to select a database engine that supports that cap=
ability, which always means a client/server
database engine.

    SQLite only supports one writer at a time per database file. But in m=
ost cases, a write transaction only takes
milliseconds and so multiple writers can simply take turns. SQLite will h=
andle more write concurrency that many people
suspect. Nevertheless, client/server database systems, because they have =
a long-running server process at hand to
coordinate access, can usually handle far more write concurrency than SQL=
ite ever will.

 * Big data? =E2=86=92 choose client/server

    If your data will grow to a size that you are uncomfortable or unable=
 to fit into a single disk file, then you
should select a solution other than SQLite. SQLite supports databases up =
to 140 terabytes in size, assuming you can find
a disk drive and filesystem that will support 140-terabyte files. Even so=
, when the size of the content looks like it
might creep into the terabyte range, it would be good to consider a centr=
alized client/server database.

 * Otherwise =E2=86=92 choose SQLite!

    For device-local storage with low writer concurrency and less than a =
terabyte of content, SQLite is almost always a
better solution. SQLite is fast and reliable and it requires no configura=
tion or maintenance. It keeps thing simple.
SQLite "just works".


--eAkWfilHHBdGkaWL6iStq8cn8TLXI1cBf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJU5WOGAAoJENZ7D1rrH75NHO8P/R4yQ1vUaVEuz9wlldSglARz
A2qkRNfc42OFOZk+jmJzapm4xH9u42gfd4v9FwFXojMI+ng4RSt/wEx9JvhzFl0S
leGtxILGxuIeXvvzKq5US/5sitRdCQuUr+ZzIT0ctAt5irIcBkugAdIgfdnWCWsT
rdNQNcHAJhNqge8voEsjccaCgG+Y71L0CV0jR8QQAt779uxRexCw4jQT6kSfOBpQ
iXyfYziyqiwkmgNeLi5VhHwL/qiTAtmZvr6+ld1WWh/NLUFm2X8J3pvSXAUNRB+P
RzWWj85MdX23rg/DLqSHYGuKh5BCieUuVoejywwZCJJV9g1pvm+iMrjYUOhPBiw4
5UiWeQ1V9EBL6HeL6M8RwPObTOC5FOzXpAcFi002RlAMvJd4MmFEfkqAbLCvrjr1
eIHqs2k5jW31mvIH/XcX41RaRDGbHHsznFrfLWkm6LvtNFldAp/h/9eXZXfQvlve
G6dsuLi8RUvBZcH+yObWCA/g5+h1t8nJibhOQ4HwN1R3xXUu8Ftb7dLEzd1W6X7a
d0eroNyS29qwcctc1pmsj+FPYEdwBu+Mv3L8KLJgg6JAhfXCI5UfK5tKiLSnQZk0
k4aZ+8woctIX5qM0gFJyS2j1lKMmPW8CmDHSCxyqACEv+DmVc4kvgCUx+ubTBtrA
M5DxswMLQVzEwXeDwmE0
=45Ux
-----END PGP SIGNATURE-----

--eAkWfilHHBdGkaWL6iStq8cn8TLXI1cBf--