Philip Withnall
philip.withnall@collabora.co.uk 2015

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Als besondere Ausnahme gewähren die Inhaber des Urheberrechts die Erlaubnis, den Beispiel-Code in diesem Dokument ohne Einschränkungen unter den Bedingungen Ihrer Wahl zu kopieren, zu verändern und weiterzugeben.

Simple persistent object stores
Mario Blättermann
mario.blaettermann@gmail.com 2016, 2018
Christian Kirbach
christian.kirbach@gmail.com 2016, 2020
Stefan Melmuk
stefan.melmuk@gmail.com 2018
Tim Sabsch
tim@sabsch.com 2021

# Datenbanken

#

        Zusammenfassung

          Verwenden Sie Datenbanken für die entsprechenden Anwendungsfälle: Nicht für Konfigurationsdaten (verwenden Sie dann GSettings). ()
          Wählen Sie zwischen GOM und GVDB, abhängig davon, ob Indizierung erforderlich ist ().

            Consider your vacuuming policy before committing to using GOM.
            ()

            Avoid SQL injection vulnerabilities by using prepared statements.
            ()

# Anwendungsfälle für Datenbanken

Configuration data should be stored in GSettings. As a rule of thumb, if some data needs to be persistent and affects how an application behaves, it is configuration data. If it could potentially be subject to policies imposed by the system administrator (such as proxy or lockdown settings), it is configuration data. If it contains user created content, it is not configuration data, and should not be stored in GSettings.

For such situations where user data is highly structured, storing it in a database is sensible. There are two main databases suggested for use within GNOME: GOM and GVDB. GOM is a wrapper around SQLite, and hence implements indexing of fields and SQL-style queries. GVDB is a much simpler object store, supporting fast serialization of a dictionary of objects to disk.

GOM sollte verwendet werden, wenn Sie erweiterte Funktionsmerkmale benötigen, insbesondere Indizierung. Anderenfalls verwenden Sie GVDB.

Before deciding to use GOM (and hence SQLite), you must consider a vacuuming policy for the database, and whether your use case will interact well with SQLite’s vacuuming system. Vacuuming is effectively SQLite’s term for defragmenting the database — if a database is not vacuumed appropriately, performance will degrade and the database size will increase indefinitely. Read this article on vacuuming for more information; please consider it before choosing to use GOM.

GNOME has another database library: GNOME Data Access (GDA). This is targeted at abstracting access to various types of relational database, for use in a database utility program or office program, for example. It is not suitable for storing user settings.

# Verwendung von GOM

Die Bereitstellung eines GOM-Tutorials würde den Rahmen dieses Dokuments sprengen, aber ein Referenzhandbuch ist verfügbar.

## SQL-Einschleusung

GOM does allow access to the lower level SQLite query APIs. When using them, queries must be constructed using SQLite’s prepared statement and value binding API, rather than by constructing SQL strings then passing them to SQLite to parse. Constructing strings makes SQL injection vulnerabilities very likely, which can give attackers access to arbitrary user data from the database.

# GVDB verwenden

GVDB has a simple API which mirrors a conventional hash table. Presently, GVDB is only available as a copy-and-paste library; fetch the most recent copy of the code from GVDB git and copy it into your project. It is licensed under LGPLv2.1+.

A full GVDB tutorial is beyond the scope of this document.