Documentation Source Text

Check-in [89971860f6]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Tweaks to the "application file format" use case description.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 89971860f64f5cb166a47ce33cd24eb019e7f7ba
User & Date: drh 2013-05-19 21:21:21.650
Context
2013-05-20
05:41
Add the sha1 hash and SQLITE_SOURCE_ID for 3071700 to changes.html. (check-in: e87984f1c8 user: dan tags: trunk)
2013-05-19
21:21
Tweaks to the "application file format" use case description. (check-in: 89971860f6 user: drh tags: trunk)
2013-05-18
17:45
Documentation updates for version 3.7.17. (check-in: 67d025e82c user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/whentouse.in.
︙︙
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


<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:
</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> 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>








|
















|












|









|








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


<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:
</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> 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>
︙︙