Important announcement: there is an English version of this forum on
Datum:
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
Datum:
(wenn es nicht gerade millionen an parametern sind) ein lock file und ein file für die parameter und fertig
Datum:
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.
Datum:
> (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
Datum:
>deswegen mindestens 3 Tabellen
warum, einfach 3 spalten (pro datentyp eine)
Datum:
> 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.
Autor:
Läubi ..
(laeubi)
(Moderator)
Datum:
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.
Datum:
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.
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten