Parameter-Verwaltung mit Datenbanken

[Jürgen W. (lovos)]

Hallo,
für eine Steuerungsanwendung (C++) auf einem Alix-Board unter Linux 
brauche ich eine Lösung, wie ich Parameter verwalten kann.
Die Parameter können durch webserver (appweb) geändert werden, durch 
LAN-Netzwerk, möglicherweise auch andere Netzwerke, da mehrere Boards 
vernetzt sind und ein Master die Parameter seiner Slaves ändern kann.
Bei Änderung beeinflussen sie die Regelung.


Meine erste Idee war sqlite3.
Nun ist ja das kein typischer Fall für Relationale Datenbanken, aber 
grundsätzlich machbar. (eine spalte Parametername varchar(16), andere 
Spalten Wert, min/max-Grenzen, Zugriffsrechte, ...)

Welche Alternativen gibt es?
Auf die Parameter wird von verschiedenen Prozessen/Threads zugegriffen.
Gruss

[Robert L. (lrlr)]

(wenn es nicht gerade millionen an parametern sind)

ein lock file und ein file für die parameter und fertig

[Patrick (Gast)]

Insbesondere mit der Zugriffsrechte-Sache halte ich SQLite für eine gar 
nicht mal so falsche Wahl - insbesondere, wenn man die Zugriffsrechte 
noch etwas hierarchisch aufsplitten möchte (z. B. nach Anwendung, 
Benutzergruppen etc.), ist es schon sehr komfortabel, das Ganze 
"dreidimensional" über mehrere Tabellen aufteilen zu können.
Auch spart man sich durch integriertes Locking, Journaling usw. doch 
schon Einiges an Arbeit außenherum.

Eine Alternative wäre vielleicht noch eine NoSQL-Datenbank wie 
DesktopCouch.

Aber von der Verwendung "einfacher" Config-Files würde ich speziell im 
Hinblick auf die Rechteverwaltung absehen - zumal das Parsen etc. ja 
auch einen nicht unerheblichen Aufwand erfordert, der kaum geringer als 
eine "richtige" Datenbank ausfallen dürfte.

[Jürgen W. (lovos)]

> (wenn es nicht gerade millionen an parametern sind)

hundert sind es schon.
Allerdings verschiedene Typen, 95% sind 'int', der Rest 'string' und 
'float'.
Und das ist nicht so schön, da ich deswegen mindestens 3 Tabellen 
brauche.

> eine NoSQL-Datenbank wie DesktopCouch.

Das schaue ich mir mal an

[Robert L. (lrlr)]

>deswegen mindestens 3 Tabellen

warum, einfach 3 spalten (pro datentyp eine)

[Jürgen W. (lovos)]

> warum, einfach 3 spalten (pro datentyp eine)

Dann auch extra Spalten für Min,Max, Default-Value ...

Ich hatte schon überlegt, eine Mastertable zu erstellen mit Spalten 
"Variablen-Name" und Referenz.
Die Referenz kann auf eine Zeile in einer der 3 Tabellen verweisen.
Aber das scheint mit sqlite nicht möglich zu sein.

[Läubi .. (laeubi)]

Nur so als Hinweis du kannst verschiedene Datentypen in einer SQLite 
Spalte speichern:
http://www.sqlite.org/faq.html#q3
Müßtest also nur für dich eine Spalte haben wo du dir merkst ob gerade 
ein int/boolean/float drinsteht.

[Joachim D. (Firma: JDCC) (scheppertreiber)]

Patrick schrieb:
> Aber von der Verwendung "einfacher" Config-Files würde ich speziell im
> Hinblick auf die Rechteverwaltung absehen - zumal das Parsen etc. ja
> auch einen nicht unerheblichen Aufwand erfordert, der kaum geringer als
> eine "richtige" Datenbank ausfallen dürfte.

Ich arbeite gerne mit SQLite.

Aber da ist das echt mit Kanonen auf Spatzen geschossen. Nebenbei
spielt auch die Performance eine Rolle. SQL ist, im Vergleich zu
"normalen" Textdateien, grottenlangsam.

Nebenbei mußt die aus der Datenbank erhaltenen Werte ja auch erst
einmal interpretieren - das nimmt Dir keine Datenbank ab.

In einer Webanwendung dann einfach die Textdatei komplett laden,
modfizieren und wieder ablegen.