Pong

## June 18th 2014, SQLite

Transmissions that arrive on the server must be stowed away. Later on they may be removed or transferred to another destination, but first the transmissions need to be kept in a safe way. A convenient way to do this is SQLite.

A SQLite database is mapped to a single file, which contains data stored in a key/value schema. To store a bunch of files in a SQLite database, we simply use a key/value schema with the key being the file name and the value being a blob with the file contents. In the high-level SQL language description such a schema is created with the following SQL statement:

CREATE TABLE files(filename TEXT PRIMARY KEY, content BLOB);


If the data is stored in a compressed format (e.g. using qCompress()), then the database is not much larger than the same amount of data stored in a zip file. Nevertheless, it is much easier to access the stored data because:

• The database can be queried with the SQL high-level languange.
• Any amount of data tables or relations can be stored in the db as well.
• Transactions on the database are safe, meaning that a power failure cannot corrupt the data.
• Transactions are thread-safe, also.
• Since that data is contained in a single file, it is easy to back up.
• The database format is platform independent
• File names do not need to adhere to any platform specific conventions, since they are just a key text string in the database table.
• No need to waste time thinking about efficient storage of the data, the SQLite database developers have already arranged everything for us.
• SQLite is stable and tested.
• SQLite is a server-less database. It is a so-called application embedded database, so there is no concept of users and passwords, but there is also zero configuration overhead.
• External access to the database is possible through widely available maintenance and statistics tools.
• The entire source code of SQLite is in the public domain, so it is completely free to use.