Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Updates to the application-file-format text. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
9811172daa665f1b6ebf20b4faf40005 |
User & Date: | drh 2013-05-03 17:42:59.942 |
Context
2013-05-03
| ||
17:51 | Still more edits to the application file format text. (check-in: 6ef8771745 user: drh tags: trunk) | |
17:42 | Updates to the application-file-format text. (check-in: 9811172daa user: drh tags: trunk) | |
15:43 | Add documentation for the Application ID. Add a proposed release date for 3.7.17. (check-in: 0d800b73f2 user: drh tags: trunk) | |
Changes
Changes to pages/intern-v-extern-blob.in.
1 2 3 4 5 6 7 | <title>Internal Versus External BLOBs</title> <body> <h1 align="center"> Internal Versus External BLOBs in SQLite </h1> <p> | > | 1 2 3 4 5 6 7 8 | <tcl>hd_keywords {BLOB I/O performance} {Internal Versus External BLOBs}</tcl> <title>Internal Versus External BLOBs</title> <body> <h1 align="center"> Internal Versus External BLOBs in SQLite </h1> <p> |
︙ | ︙ |
Changes to pages/whentouse.in.
︙ | ︙ | |||
59 60 61 62 63 64 65 | <tcl>hd_fragment appfileformat {application file-format}</tcl> <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 | | | | | < < < < < > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | > > > > > > > > > | 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 | <tcl>hd_fragment appfileformat {application file-format}</tcl> <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 calls sqlite3_open() to attach to the database file. Updates to the file happen atomically as the file is edited, so the File/Save menu option become superfluous. The File/Save_As menu option can be implemented using the [backup API]. </p> <p> There are many advantages to using SQLite as an application file format, including: </p> <ol type="1"> <li> There is no file parsing and generating code to write and debug. <li> Content can be accessed and updated using powerful SQL queries, greatly reducing the complexity of the application code. <li> Extending the file format for new capabilities in later releases is a simple as adding new tables or new columns to existing tables. <li> The content can be viewed using third-party tools. <li> The application file is portable across all operating systems, 32-bit and 64-bit and big- and little-endian architectures. <li> The application only has to load as much data as it needs, rather than reading the entire application file and holding a complete parse in memory. Startup time and memory consumption are reduced. <li> Small content edits only overwrite the parts of the file that change, not the entire file, thus improving performance and reducing wear on SSD drives. <li> Content is updated continously and atomically so that there is no work lost in the event of a power failure or crash. <li> Applications can leverage the [full-text search] and [RTREE] capablities that are build into SQLite. <li> Performance problems can often be resolved using [CREATE INDEX] rather than redesigning, rewriting, and retesting application code. <li> A federation of programs, perhaps written in different programming languages, can all access the same application file with no compatibility concerns. <li> Multiple processes can attach to the same application file and can read and write without interfering with each another. <li> Cross-session undo/redo can be implemented using triggers. <li> In many common cases, loading content from an SQLite database can be much faster than loading content out of individual files. See [Internal Versus External BLOBs] for additional information. <li> Content stored in an SQLite database is more likely to be recoverable decades in the future, long after all traces of the original application have been lost. Data lives longer than code. </ol> <p> SQLite allows database files to have any desired filename extension, so an application can choose a custom filename extension for its own use, if desired. The [application_id pragma] can be used to set an "Application ID" integer in the database file so that tools like [http://www.darwinsys.com/file/ | file(1)] can determine that the file is associated with your application and is not just a generic SQL database.</p> <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 |
︙ | ︙ | |||
220 221 222 223 224 225 226 | 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> | | | | | < < < < | 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 | 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>An SQLite database is limited in size to 140 terabytes (2<sup><small>47</small></sup> bytes, 128 tibibytes). And even if it could handle larger databases, SQLite stores the entire database in a single disk file and many filesystems limit the maximum size of files to something less than this. So if you are contemplating databases of this magnitude, you would do well to consider using a client/server database engine that spreads its content across multiple disk files, and perhaps across multiple volumes. </p> </li> <li><p><b>High Concurrency</b></p> <p> SQLite supports an unlimited number of simultaneous readers, but it will only allow one writer at any instant in time. 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 applications that require more concurrency, and those applications may need to seek a different solution. </p> </li> </ul> |