1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" xmlns:xi="http://www.w3.org/2003/XInclude" type="topic" id="databases" xml:lang="de">
<info>
<link type="guide" xref="index#specific-how-tos"/>
<credit type="author copyright">
<name>Philip Withnall</name>
<email its:translate="no">philip.withnall@collabora.co.uk</email>
<years>2015</years>
</credit>
<include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>
<desc>Simple persistent object stores</desc>
<mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
<mal:name>Mario Blättermann</mal:name>
<mal:email>mario.blaettermann@gmail.com</mal:email>
<mal:years>2016, 2018</mal:years>
</mal:credit>
<mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
<mal:name>Christian Kirbach</mal:name>
<mal:email>christian.kirbach@gmail.com</mal:email>
<mal:years>2016, 2020</mal:years>
</mal:credit>
<mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
<mal:name>Stefan Melmuk</mal:name>
<mal:email>stefan.melmuk@gmail.com</mal:email>
<mal:years>2018</mal:years>
</mal:credit>
<mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
<mal:name>Tim Sabsch</mal:name>
<mal:email>tim@sabsch.com</mal:email>
<mal:years>2021</mal:years>
</mal:credit>
</info>
<title>Datenbanken</title>
<synopsis>
<title>Zusammenfassung</title>
<list>
<item><p>Verwenden Sie Datenbanken für die entsprechenden Anwendungsfälle: Nicht für Konfigurationsdaten (verwenden Sie dann GSettings). (<link xref="#when-to-use-databases"/>)</p></item>
<item><p>Wählen Sie zwischen GOM und GVDB, abhängig davon, ob Indizierung erforderlich ist (<link xref="#when-to-use-databases"/>).</p></item>
<item><p>
Consider your vacuuming policy before committing to using GOM.
(<link xref="#when-to-use-databases"/>)
</p></item>
<item><p>
Avoid SQL injection vulnerabilities by using prepared statements.
(<link xref="#sql-injection"/>)
</p></item>
</list>
</synopsis>
<section id="when-to-use-databases">
<title>Anwendungsfälle für Datenbanken</title>
<p>
Configuration data should be stored in
<link href="https://developer.gnome.org/gio/stable/GSettings.html">GSettings</link>.
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.
</p>
<p>
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.
</p>
<p>GOM sollte verwendet werden, wenn Sie erweiterte Funktionsmerkmale benötigen, insbesondere Indizierung. Anderenfalls verwenden Sie GVDB.</p>
<p>
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
<link href="http://blogs.gnome.org/jnelson/2015/01/06/sqlite-vacuum-and-auto_vacuum/">this
article</link> on vacuuming for more information; please consider it
before choosing to use GOM.
</p>
<p>
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
<link href="https://developer.gnome.org/gio/stable/GSettings.html">user
settings</link>.
</p>
</section>
<section id="gom">
<title>Verwendung von GOM</title>
<p>Die Bereitstellung eines GOM-Tutorials würde den Rahmen dieses Dokuments sprengen, aber ein <link href="https://developer.gnome.org/gom/">Referenzhandbuch ist verfügbar</link>.</p>
<section id="sql-injection">
<title>SQL-Einschleusung</title>
<p>
GOM does allow access to the lower level SQLite query APIs. When using
them, queries <em style="strong">must</em> be constructed using
SQLite’s <link href="https://www.sqlite.org/c3ref/stmt.html">prepared
statement</link> and
<link href="https://www.sqlite.org/c3ref/bind_blob.html">value
binding</link> API, rather than by constructing SQL strings then passing
them to SQLite to parse. Constructing strings makes
<link href="https://en.wikipedia.org/wiki/SQL_injection">SQL
injection</link> vulnerabilities very likely, which can give attackers
access to arbitrary user data from the database.
</p>
</section>
</section>
<section id="gvdb">
<title>GVDB verwenden</title>
<p>
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
<link href="https://gitlab.gnome.org/GNOME/gvdb">GVDB git</link> and copy
it into your project. It is licensed under LGPLv2.1+.
</p>
<p>
A full GVDB tutorial is beyond the scope of this document.
</p>
</section>
</page>
|
