Documentation Source Text

<p>
SQLite has been used with great success as the on-disk file format
for desktop applications such as version control systems,
financial analysis tools, media cataloging and editing suites, 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:
................................................................................
<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> Diverse content which might otherwise be stored as a "pile-of-files"
     can be encapsulated into a single easily managed disk file.
<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 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>

<p>
SQLite has been used with great success as the on-disk file format
for desktop applications such as version control systems,
financial analysis tools, media cataloging and editing suites, CAD
packages, record keeping programs, and so forth.  The traditional
File/Open operation calls sqlite3_open() to attach to the database
file.  Updates happen atomically as application content is revised
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:
................................................................................
<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> Diverse content which might otherwise be stored as a "pile-of-files"
     can be encapsulated into a single disk file.
<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 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 built 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
     is 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>