Use bancos de dados para casos de uso apropriados: não para dados de configuração (use GSettings). ()
Escolha entre GOM e GVDB com base em se indexação é necessária. ()
Considere sua política de vacuuming antes de usar GOM. ()
Evite vulnerabilidades de injeção SQL usando as instruções preparadas. ()
Dados de configuração devem ser armazenados em GSettings. Como uma regra de ouro, se alguns dados precisam ser persistentes e afetam como um aplicativo se comporta, eles são dados de configuração. Se eles estão potencialmente sujeitos a políticas impostas pelo administrador do sistema (tal como configurações de proxy e bloqueio), são dados de configuração. Se eles contêm conteúdo criado por usuários, não são dados de configuração e não devem ser armazenados em GSettings.
Para tais situações nas quais dados de usuário estejam altamente estruturado, armazená-los em um banco de dados é sensível. Há dois bancos de dados principais sugeridos para usar com GNOME: GOM e GVDB. GOM é um interfaceador do SQLite e, portanto, implementa indexação de campos e consultas no tipo SQL. GVDB é um armazenamento de objeto muito mais simples, oferecendo suporte a serialização rápida de um dicionário de objetos para disco.
GOM deve ser usado se você precisa de recursos avançados, especialmente indexação. Do contrário, GVDB deve ser usado.
Antes de decidir por usar o GOM (e, portanto, SQLite), você deveria considerar uma política de vacuuming para o banco de dados e se seu caso de uso vai interagir bem com o sistema de vácuo do SQLite. Vaccuming é, efetivamente, o termo para desfragmentação do banco de dados — se um banco de dados não for adequadamente aspirado, o desempenho será degradado e seu tamanho vai aumentar indefinidamente. Leia este artigo sobre vacuuming para mais informações; considere-o antes de escolher usar GOM.
GNOME possui uma outra biblioteca de banco de dados: GNOME Data Access (GDA). Ela visa abstrair o acesso a vários tipos de banco de dados relacionais, para uso em um programa utilitário de banco de dados ou programa de escritório, por exemplo. Ela não é adequado para armazenar configurações de usuários.
Fornecer um tutorial do GOM vai além do escopo deste documento, mas um manual de referência está disponível.
GOM não permite acesso às APIs de consulta de baixo de nível do SQLite. Ao usá-las, as consultas devem ser construídas usando a API de prepared statement (instrução preparada) e value binding (associação de valor) do SQLite, em vez de construir strings SQL e, então, passá-las para o SQLite interpretar. Construir strings possibilita as vulnerabilidades da injeção de SQL, o que pode fornecer acesso aos atacantes a dados de usuários a partir do banco de dados.
GVDB possui uma API simples que espelha a tabela de hash convencional. Atualmente, GVDB está disponível apenas como uma biblioteca de copiar-e-colar; obtenha a cópia mais recente do código de GVDB git e copie-o para seu projeto. Ele está licenciado sob LGPLv2.1+.
Um tutorial completo do GVDB vai além do escopo deste documento.