From: drh Date: Tue, 27 Jan 2004 15:58:37 +0000 (+0000) Subject: Add a web page describing when it is appropriate to use SQLite and when it X-Git-Tag: version-3.6.10~4869 X-Git-Url: http://git.ipfire.org/gitweb/gitweb.cgi?a=commitdiff_plain;h=11437fa6b153859c9a69c24ea9760e1f19f09075;p=thirdparty%2Fsqlite.git Add a web page describing when it is appropriate to use SQLite and when it is not. (CVS 1199) FossilOrigin-Name: d77e47764818ef495894013fb26b1a510f2f1a7e --- diff --git a/manifest b/manifest index d861563460..a429eccc10 100644 --- a/manifest +++ b/manifest @@ -1,5 +1,5 @@ -C Modularize\sthe\scolumn\sname\sresolution\scode\sso\sthat\sit\sis\ssmaller,\sfaster,\nand\sready\sfor\ssome\senhancements\sthat\swill\sfix\slong-standing\sname\nresolutions\sproblems.\s(CVS\s1198) -D 2004-01-25T22:44:59 +C Add\sa\sweb\spage\sdescribing\swhen\sit\sis\sappropriate\sto\suse\sSQLite\sand\swhen\sit\nis\snot.\s(CVS\s1199) +D 2004-01-27T15:58:38 F Makefile.in 0515ff9218ad8d5a8f6220f0494b8ef94c67013b F Makefile.linux-gcc b86a99c493a5bfb402d1d9178dcdc4bd4b32f906 F README f1de682fbbd94899d50aca13d387d1b3fd3be2dd @@ -181,7 +181,8 @@ F www/speed.tcl 2f6b1155b99d39adb185f900456d1d592c4832b3 F www/sqlite.tcl 3c83b08cf9f18aa2d69453ff441a36c40e431604 F www/tclsqlite.tcl b9271d44dcf147a93c98f8ecf28c927307abd6da F www/vdbe.tcl 9b9095d4495f37697fd1935d10e14c6015e80aa1 -P 3626f6d4a1adb4209d5bd9e6477343b52bddbdf2 -R dd7edf82e94deb20012095d659a5fe16 +F www/whentouse.tcl a8335bce47cc2fddb07f19052cb0cb4d9129a8e4 +P d3648034b409822909d79eb5aa4e64cafa986541 +R 09ffcac6450729a067d4f6d8020881e5 U drh -Z cf295a8614ac26ab40dca8b761e6d91c +Z 6b879081bfc399734855dd0b9bd013b6 diff --git a/manifest.uuid b/manifest.uuid index e552cac47c..d47ca99479 100644 --- a/manifest.uuid +++ b/manifest.uuid @@ -1 +1 @@ -d3648034b409822909d79eb5aa4e64cafa986541 \ No newline at end of file +d77e47764818ef495894013fb26b1a510f2f1a7e \ No newline at end of file diff --git a/www/whentouse.tcl b/www/whentouse.tcl new file mode 100644 index 0000000000..a47fbf04fe --- /dev/null +++ b/www/whentouse.tcl @@ -0,0 +1,266 @@ +# +# 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 { +Appropriate Uses of SQLite + +

Appropriate Uses Of SQLite

+} +puts "

+(This page was last modified on [lrange $rcsid 3 4] UTC) +

" + +puts { +

+SQLite is different from most other SQL database engines in that its +primary design goal is to be simple: +

+ +

Simple to administer
Simple to operate
Simple to use in a program
Simple to maintain and customize

+ +

+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. +

+ +

+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. +

+ +

+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. +

+ +

Situations Where SQLite Works Well

+ +

Websites
+ +
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.
+
Embedded devices and applications
+ +
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. +
+
Application File Format
+ +
+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. +
+ +
+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. +
+
Replacement for ad hoc disk files
+ +
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 ad hoc data files.
+
Internal or temporary databases
+ +
+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. +
+
Command-line dataset analysis tool
+ +
+Experienced SQL users can employ +the command-line sqlite 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. +
+ +
+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. +
+
Stand-in for an enterprise database during demos or testing
+ +
+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. +
+
Database Pedagogy
+ +
+Because it is simple to setup and use (installation is trivial: just +copy the sqlite or sqlite.exe 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. +
+
Experimental SQL language extensions
+ +
The simple, modular design of SQLite makes it a good platform for +prototyping new, experimental database language features or ideas. +
+

+ +

Situations Where Another RDBMS May Work Better

+ +

Client/Server Applications
+ +
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.
+ +
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.
+
High-volume Websites
+ +
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.
+
Very large datasets
+ +
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. +
+
High Concurrancy
+ +
+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. +
+

+ +} + + +puts { +

+ +Back to the SQLite home page +

+ +}