267 lines
9.7 KiB
Tcl
267 lines
9.7 KiB
Tcl
#
|
|
# Run this TCL script to generate HTML for the goals.html file.
|
|
#
|
|
set rcsid {$Id: whentouse.tcl,v 1.1 2004/01/27 15:58:38 drh Exp $}
|
|
|
|
puts {<html>
|
|
<head><title>Appropriate Uses of SQLite</title></head>
|
|
<body bgcolor=white>
|
|
<h1 align=center>Appropriate Uses Of SQLite</h1>
|
|
}
|
|
puts "<p align=center>
|
|
(This page was last modified on [lrange $rcsid 3 4] UTC)
|
|
</p>"
|
|
|
|
puts {
|
|
<p>
|
|
SQLite is different from most other SQL database engines in that its
|
|
primary design goal is to be simple:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>Simple to administer</li>
|
|
<li>Simple to operate</li>
|
|
<li>Simple to use in a program</li>
|
|
<li>Simple to maintain and customize</li>
|
|
</ul>
|
|
|
|
<p>
|
|
Many people like SQLite because it is small and fast. But those
|
|
qualities are just happy accidents.
|
|
Users also find that SQLite is very reliable. Reliability is
|
|
a consequence of simplicity. With less complication, there is
|
|
less to go wrong. So, yes, SQLite is small, fast, and reliable,
|
|
but first and foremost, SQLite strives to be simple.
|
|
</p>
|
|
|
|
<p>
|
|
Simplicity in a database engine can be either a strength or a
|
|
weakness, depending on what you are trying to do. In order to
|
|
achieve simplicity, SQLite has had to sacrifice other characteristics
|
|
that some people find useful, such as high concurrancy, fine-grained
|
|
access control, a rich set of built-in functions, stored procedures,
|
|
esoteric SQL language features, XML and/or Java extensions,
|
|
tera- or peta-byte scalability, and so forth. If you need these
|
|
kinds of features and don't mind the added complexity that they
|
|
bring, then SQLite is probably not the database for you.
|
|
SQLite is not intended to be an enterprise database engine. It
|
|
not designed to compete with Oracle or PostgreSQL.
|
|
</p>
|
|
|
|
<p>
|
|
The basic rule of thumb for when it is appropriate to use SQLite is
|
|
this: Use SQLite in situations where simplicity of administration,
|
|
implementation, and maintenance are more important than the countless
|
|
complex features that enterprise database engines provide.
|
|
As it turns out, situations where simplicity is the better choice
|
|
are more common that many people realize.
|
|
</p>
|
|
|
|
<h2>Situations Where SQLite Works Well</h2>
|
|
|
|
<ul>
|
|
<li><p><b>Websites</b></p>
|
|
|
|
<p>SQLite usually will work great as the database engine for low to
|
|
medium traffic websites (which is to say, 99.9% of all websites).
|
|
The amount of web traffic that SQLite can handle depends, of course,
|
|
on how heavily the website uses its database. Generally
|
|
speaking, any site that gets fewer than a 100000 hits/day should work
|
|
fine. The 100000 hits/day figure is a conservative estimate, not a
|
|
hard upper bound.
|
|
SQLite has been demonstrated to work with 10 times that amount
|
|
of traffic.</p>
|
|
</li>
|
|
|
|
<li><p><b>Embedded devices and applications</b></p>
|
|
|
|
<p>Because an SQLite database requires little or no administration,
|
|
SQLite is a good choice for devices or services that must work
|
|
unattended and without human support. SQLite is a good fit for
|
|
use in cellphones, PDAs, set-top boxes, and/or appliances. It also
|
|
works well as an embedded database in downloadable consumer applications.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p><b>Application File Format</b></p>
|
|
|
|
<p>
|
|
SQLite has been used with great success as the on-disk file format
|
|
for desktop applications such as financial analysis tools, CAD
|
|
packages, record keeping programs, and so forth. The traditional
|
|
File/Open operation does an sqlite_open() and executes a
|
|
BEGIN TRANSACTION to get exclusive access to the content. File/Save
|
|
does a COMMIT followed by another BEGIN TRANSACTION. The use
|
|
of transactions guarantees that updates to the application file are atomic,
|
|
durable, isolated, and consistent.
|
|
</p>
|
|
|
|
<p>
|
|
Temporary triggers can be added to the database to record all
|
|
changes into a (temporary) undo/redo log table. These changes can then
|
|
be played back when the user presses the Undo and Redo buttons. Using
|
|
this technique, a unlimited depth undo/redo implementation can be written
|
|
in surprising little code.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p><b>Replacement for <i>ad hoc</i> disk files</b></p>
|
|
|
|
<p>Many programs use fopen(), fread(), and fwrite() to create and
|
|
manage files of data in home-grown formats. SQLite works well as a
|
|
replacement for these <i>ad hoc</i> data files.</p>
|
|
</li>
|
|
|
|
<li><p><b>Internal or temporary databases</b></p>
|
|
|
|
<p>
|
|
For programs that have a lot of data that must be sifted and sorted
|
|
in diverse ways, it is often easier and quicker to load the data into
|
|
an in-memory SQLite database and use query with joins and ORDER BY
|
|
clauses to extract the data in the form and order needed rather than
|
|
to try to code the same operations manually.
|
|
Using an SQL database internally in this way also gives the program
|
|
greater flexibility since new columns and indices can be added without
|
|
having to recode every query.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p><b>Command-line dataset analysis tool</b></p>
|
|
|
|
<p>
|
|
Experienced SQL users can employ
|
|
the command-line <b>sqlite</b> program to analyze miscellaneous
|
|
datasets. Raw data can be imported using the COPY command, then that
|
|
data can be sliced and diced to generate a myriad of summary
|
|
reports. Possible uses include website log analysis, sports
|
|
statistics analysis, compilation of programming metrics, and
|
|
analysis of experimental results.
|
|
</p>
|
|
|
|
<p>
|
|
You can also do the same thing with a enterprise client/server
|
|
database, of course. The advantages to using SQLite in this situation
|
|
are that SQLite is much easier to set up and the resulting database
|
|
is a single file that you can store on a floppy disk or email to
|
|
a colleague.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p><b>Stand-in for an enterprise database during demos or testing</b></p>
|
|
|
|
<p>
|
|
If you are writting a client application for an enterprise database engine,
|
|
it makes sense to use a generic database backend that allows you to connect
|
|
to many different kinds of SQL database engines. It makes even better
|
|
sense to
|
|
go ahead and include SQLite in the mix of supported database and to statically
|
|
link the SQLite engine in with the client. That way the client program
|
|
can be used standalone with an SQLite data file for testing or for
|
|
demonstrations.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p><b>Database Pedagogy</b></p>
|
|
|
|
<p>
|
|
Because it is simple to setup and use (installation is trivial: just
|
|
copy the <b>sqlite</b> or <b>sqlite.exe</b> executable to the target machine
|
|
and run it) SQLite makes a good database engine for use in teaching SQL.
|
|
Students can easily create as many databases as they like and can
|
|
email databases to the instructor for comments or grading. For more
|
|
advanced students who are interested in studying how an RDBMS is
|
|
implemented, the modular and well-commented and documented SQLite code
|
|
can serve as a good basis. This is not to say that SQLite is an accurate
|
|
model of how other database engines are implemented, but rather a student who
|
|
understands how SQLite works can more quickly comprehend the operational
|
|
principles of other systems.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p><b>Experimental SQL language extensions</b></p>
|
|
|
|
<p>The simple, modular design of SQLite makes it a good platform for
|
|
prototyping new, experimental database language features or ideas.
|
|
</p>
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
<h2>Situations Where Another RDBMS May Work Better</h2>
|
|
|
|
<ul>
|
|
<li><p><b>Client/Server Applications</b><p>
|
|
|
|
<p>If you have many client programs access a common database
|
|
over a network, you should consider using a client/server database
|
|
engine instead of SQLite. SQLite will work over a network filesystem,
|
|
but because of the latency associated with most network filesystems,
|
|
performance will not be great. Also, the file locking logic of
|
|
many network filesystems implementation contains bugs (on both Unix
|
|
and windows). If file locking does not work like it should,
|
|
it might be possible for two or more client programs to modify the
|
|
same part of the same database at the same time, resulting in
|
|
database corruption. Because this problem results from bugs in
|
|
the underlying filesystem implementation, there is nothing SQLite
|
|
can do to prevent it.</p>
|
|
|
|
<p>A good rule of thumb is that you should avoid using SQLite
|
|
in situations where the same database will be accessed simultenously
|
|
from many computers over a network filesystem.</p>
|
|
</li>
|
|
|
|
<li><p><b>High-volume Websites</b></p>
|
|
|
|
<p>SQLite will normally work fine as the database backend to a website.
|
|
But if you website is so busy that your are thinking of splitted the
|
|
database component off onto a separate machine, then you should
|
|
definitely consider using an enterprise-class client/server database
|
|
engine instead of SQLite.</p>
|
|
</li>
|
|
|
|
<li><p><b>Very large datasets</b></p>
|
|
|
|
<p>When you start a transaction in SQLite (which happens automatically
|
|
before any write operation that is not within an explicit BEGIN...COMMIT)
|
|
the engine has to allocate a bitmap of dirty pages in the disk file to
|
|
help it manage its rollback journal. SQLite needs 256 bytes of RAM for
|
|
every 1MB of database. For smaller databases, the amount of memory
|
|
required is not a problem, but when database begin to grow into the
|
|
multi-gigabyte range, the size of the bitmap can get quite large. If
|
|
you need to store and modify more than a few dozen GB of data, you should
|
|
consider using a different database engine.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p><b>High Concurrancy</b></p>
|
|
|
|
<p>
|
|
SQLite uses reader/writer locks on the entire database file. That means
|
|
if any process is reading from any part of the database, all other
|
|
processes are prevented from writing any other part of the database.
|
|
Similarly, if any one process is writing to any part of the database,
|
|
all other processes are prevented from reading any other part of the
|
|
database.
|
|
For many situations, this is not a problem. Each application
|
|
does its database work quickly and moves on, and no lock lasts for more
|
|
than a few dozen milliseconds. But there are some problems that require
|
|
more concurrancy, and those problems will need to seek a different
|
|
solution.
|
|
</p>
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
}
|
|
|
|
|
|
puts {
|
|
<p><hr /></p>
|
|
<p>
|
|
<a href="index.html"><img src="/goback.jpg" border=0 />
|
|
Back to the SQLite home page</a>
|
|
</p>
|
|
|
|
</body></html>}
|