DB-Auswahl: FB embedded mit externem Zugriff?

[messie]

Moin,

ich habe eine Software, die lokal Daten produziert und ablegt (bisher als ASCII). Gegegentlich (also ein paarmal im Monat) greift die Qualitätssicherung übers Netz auf die Daten zu. Die Suche darin ist recht umständlich und die Datenmenge mittlerweile recht groß, so dass es lange dauert.
Für die lokale Anwendung würde sich FB embedded anbieten. Die Frage ist, wie der externe Zugriff gestaltet werden kann. Für einen Server ist mir die Sache eigentlich zu klein und es ist niemand zum Administrieren da. Alle paar Jahre wird so ein Prüfstand neu gebaut und ins chinesische Hinterland geliefert. Die brauchen dann keinen externen Zugriff. Dafür muss das alles mit einer Installationsroutine ohne besondere Eingaben klappen.
Bisher gibt es noch keine Präferenzen, für den Zugriff hatte ich dbx im Auge - die Komplexität der Aufgabe hält sich ja in Grenzen. Auch die Aktualität der Daten hat eine geringe Priorität.
Wenn man jetzt die Datenbank-Datei regelmäßig (die Intervalle müsste man noch klären) auf ein anderes Laufwerk spiegelt, müsste eine andere Installation die doch wie die lokale embedded-DB behandeln können. Ist das richtig?

Danke, Messie

[OT]Duck and Cover - Messie goes Datenbanken[/OT]

[mkinzler]

Ein Firebird-Server ist eigentlich recht administrationsarm.

[messie]

Zitat von mkinzler:

Ein Firebird-Server ist eigentlich recht administrationsarm.

Kann man den so vorkonfigurieren, dass er mit der einmaligen Eingabe eines Users und Passworts läuft, ohne dass da jemals wieder nach gesehen werden muss?

Wer möchte schon gerne ins chinesische Hinterland, vor allem auf eigene Kosten

Grüße, Messie

[user0815]

Warum nicht SQLite? Die QS könnte sich dann einfach die DB ziehen / zukommen lassen.

[mkinzler]

Zitat von user0815:

Warum nicht SQLite? Die QS könnte sich dann einfach die DB ziehen / zukommen lassen.

Selbiges gilt für Firebird (embedded)

Zitat:

Kann man den so vorkonfigurieren, dass er mit der einmaligen Eingabe eines Users und Passworts läuft, ohne dass da jemals wieder nach gesehen werden muss?

Der Server wird standardmässig mit SYSDBA / masterkey installiert.

[tsteinmaurer]

Was heißt:

Zitat:

greift die Qualitätssicherung übers Netz auf die Daten zu

Per SQL oder kopieren der Daten auf Dateisystemebene?

Im Prinzip steht dir mit Firebird alles offen: Regulärer Firebird Server mit User/Passwort Anlage als Post-Task deines Installers, oder du nimmst den Default SYSDBA/masterkey (allerdings nicht zu empfehlen). Embedded hernehmen, wo kein Multi-User Zugriff übers Netz möglich ist, sondern z.B. Kopie der Datenbank, wenn niemand verbunden ist etc.

[messie]

Zitat von tsteinmaurer:

Was heißt:

Zitat:

greift die Qualitätssicherung übers Netz auf die Daten zu

Per SQL oder kopieren der Daten auf Dateisystemebene?

Bisher noch auf die ASCII-Daten, die auf einem Dateiserver liegen. Sowohl am Prüfstand als auch in der QS wird dasselbe Programm verwendet, nur dass in der QS die Datenaufnahme mangels Hardware deaktiviert ist.

Zitat von user0815:

Warum nicht SQLite? Die QS könnte sich dann einfach die DB ziehen / zukommen lassen.

Wir haben noch ein weiteres Programm, in dem eine Interbase 6 verbaut ist. Die könnte evtl. mal ihrem Programmierer in den Ruhestand folgen und dann stelle ich mir den Umstieg auf Firebird deshalb leichter vor, weil damit sehr viel Erfahrung vorliegt. Und daher bin ich bei der Auswahl ganz leicht in die Richtung fokussiert.

Zitat von tsteinmaurer:

Im Prinzip steht dir mit Firebird alles offen: Regulärer Firebird Server mit User/Passwort Anlage als Post-Task deines Installers(...)

Da möchte ich noch mal nachfragen, wie ich mir das vorstellen kann. Etwa: Installation mit manueller Festlegung des DB-Pfads, nach Abschluss der Aufruf eines mitinstallierten Konfigurationsprogramms mit entsprechenden Parametern ohne GUI oder Aufruf mit GUI?
Wie sieht es dann mit den Zugriffsrechten aus? Darf die QS-Installation mit denselben Userdaten zugreifen? Dort würde ich dann eine manuelle Konfiguration vorsehen.
Eine einmalige Eingabe eines Passworts/Benutzernamens kann man ja als Anleitung mitgeben. Aber nur, wenn für alle Installationen derselbe Anmeldename zulässig wäre.

Hört sich alles schon mal gut an

Danke, Messie

[mkinzler]

Zitat:

Die könnte evtl. mal ihrem Programmierer in den Ruhestand folgen und dann stelle ich mir den Umstieg auf Firebird deshalb leichter vor, weil damit sehr viel Erfahrung vorliegt. Und daher bin ich bei der Auswahl ganz leicht

Zudem hat FB den Vorteil, dass man leicht auf einen Server migrieren kann.

Zitat:

Da möchte ich noch mal nachfragen, wie ich mir das vorstellen kann. Etwa: Installation mit manueller Festlegung des DB-Pfads, nach Abschluss der Aufruf eines mitinstallierten Konfigurationsprogramms mit entsprechenden Parametern ohne GUI oder Aufruf mit GUI?

Das ist kein Problem.

Zitat:

Wie sieht es dann mit den Zugriffsrechten aus? Darf die QS-Installation mit denselben Userdaten zugreifen? Dort würde ich dann eine manuelle Konfiguration vorsehen.

Man kann auch verschiedene Benutzer (am Server) anlegen und denen in der Datenbank verschiedene Rechte/Sichten einrichten.

[messie]

Man kann auch verschiedene Benutzer (am Server) anlegen und denen in der Datenbank verschiedene Rechte/Sichten einrichten.[/QUOTE]
AUCH heißt, dass sich EIN user von zwei Standorten gleichzeitig anmelden kann?
Unterscheidliche Rechte und Sichten sind hier gar nicht nötig.

Grüße, Messie

[tsteinmaurer]

Zitat:

AUCH heißt, dass sich EIN user von zwei Standorten gleichzeitig anmelden kann?

Im Falle eines dezidierten Firebird Server Prozess, ja, natürlich. Das ist Sinn und Zweck eines multi-user fähigen DBMS, dass mehrere User gleichzeitig die Datenbank abfragen etc. können.