Virtual tables are typically used to link the SQLite database engine to an alternate data source. There are two general categories of virtual tables: internal and external. There aren’t any implementation differences between the categories, they just provide a rough way to define a module’s functionality.
Internal modules are self-contained within the database. That is, the virtual table acts as a fancy front-end to more traditional database tables that are created and maintained by the virtual table module. These back-end tables are sometimes known as shadow tables. Most importantly, all the data used by the module is still stored within the database file. These types of modules typically provide a specialized type of indexing or lookup feature that is not well suited to the native database indexes. Internal virtual tables may require multiple shadow tables to efficiently operate.
The two largest modules included in the SQLite distribution (FTS3 and R*Trees) are both internal style modules. Both of these modules create and configure several standard tables to store and index the data they’ve been asked to maintain.
Generally, internal modules are used to improve or extend the data manipulation facilities of a database. In most cases, an internal virtual table isn’t doing anything an SQL developer couldn’t do on their own, the module is just making it easier or faster (or both). Internal modules often play the role of an abstract “smart view” that offers highly optimized access patterns to specific types of data or specific structures of data. Both the Full Text Search module and the R*Tree module are prime examples of modules that provide highly specialized searches on specific types and structures of data.
The other major category of modules are external modules. These are
modules that interface with some type of external data source. That
data source might be something as simple as an external file. For
example, a module could expose a CSV file or Excel file as an SQL
table within the database. Pretty much any structured file can be
exposed this way. An external module can also be used to present other
data sources to the SQLite database engine. You could actually write
an SQLite module that exposed tables from a MySQL database to the
SQLite database engine. Or, for something a bit more unusual, have the
query SELECT ip FROM dns WHERE hostname =
'www.oreilly.com' go out and process a DNS request.
External modules can get quite exotic.
In the case of external modules, it is important to understand that the data is not imported or copied into the SQLite database. Rather than loading the data into standard tables and allowing you to access it from there, an external module acts as a real-time translator between the SQLite data structures and whatever external data source you wish to access. Modules will typically reflect changes to their data source in real time.
Of course, you can use an external module as an
importer by copying the data from a virtual table to a standard table
with an INSERT...SELECT statement.
If the module has full read/write support, you can even use it as an
exporter by copying data from the database into the virtual table. By
using this technique, I’ve seen cases of SQLite being used as a
“universal translator” for several different external data formats. By
writing a virtual table module that can speak to each file format, you
can easily and quickly move data between supported formats.
To help explain how modules work, we’re going to
work through two examples. The first example is a very simple internal
module that exposes the output of the PRAGMA
database_list
command as a full-blown table. This allows you to run
SELECT queries (including
WHERE constraints) against
the current database list. Although this module is read-only and
extremely simple, it should serve as a good first introduction to the
module system.
The second example is a bit more in-depth. We’ll be looking at building an external module that exposes Apache httpd server logs to the database engine. This allows a webmaster to run SQL queries directly against a logfile (including the active logfile) without having to first import the data into a traditional database table.
As we’ll see with the webserver logfile example, developing an external SQLite module can be an easy way to provide generic search-and-report services to arbitrary data formats. In the case of webserver logs, many server administrators have a stash of scripts and utilities they use for logfile analysis. While these can work quite well for clearly defined tasks, such scripts often require significant code modifications to alter search parameters or report formats. This can make custom scripts difficult to modify and somewhat inflexible.
Webserver log analysis is a common enough problem that there are some extremely powerful general purpose packages available for download. Some of these packages are quite robust and impressive, but to use them effectively requires understanding and experience with the package and the tools that it provides.
With the external data module, you can simply
attach the SQLite engine directly to your logfiles, making the logs
appear as a big (and constantly updating) table. Once this is done,
you have the whole power of the relational database engine at your
disposal. Best of all, the queries and searches are all defined in
SQL, a language that many web administrators already know. Report
generation becomes a snap and, when combined with the sqlite3 command-line utility, the module will enable
real-time
interaction
with the live log data. This allows a system administrator
faced with a security or performance incident to quickly formulate and
execute arbitrary searches and summary reports interactively, in a
language and environment they’re already comfortable using.
This is one of the more compelling uses of virtual tables. While there are many instances of applications that can take advantage of the custom index formats and improved search features offered by some virtual tables, the true magic happens with external modules. The ability to integrate any regular data source into a full SQL environment makes for an extremely powerful and enabling tool, especially in cases where there is a need to directly interact with the data in real time.
The next time you’re thinking about clobbering together some scripts to scan or filter a structured data source, ask yourself how hard it would be to write an SQLite module instead. Modules can definitely be tricky to write, but once you have a working module, you also have the full power of the SQL language at your hands.