Moin,
Ich habe (mit 6 Mitstreitern) eine Büchereiverwaltung entwickelt die auch soweit funktioniert. Aktuell verwenden wir SQLite und das funktioniert an sich soweit alles wunderbar.

Das Problem ist jetzt aber, dass es auch eine portable Ausleihe/Rückgabe gibt. Und bei dieser muss die Datenbank auf den Laptop übertragen werden. Dann gehen zwei Leute in die Klassenzimmer und leihen die Bücher aus. Dann gehen sie wieder zurück und synchronisieren den ganzen Kram.

Ich wollte jetzt fragen ob ein Datenbankserver wie Firebird (oder MySQL) dort besser wäre. Dann könnte man nämlich einfach immer die gleiche Software verwenden und muss nicht mehr synchronisieren oder der Laptop vorbereiten.

Das ist übrigens auch ein notwendiger Punkt, da die Namen der Schüler verschlüsselt sein sollen. Aktuell machen wir das manuell mithilfe des DEC und mit AES. Gibt es dort vielleicht schon build-in Möglichkeiten?

Außerdem der dritte "kritische" Punkt, dass es aktuell relativ langsam ist, wenn man ständig auf die Datenbank zugreife. Deshalb wird aktuell einmal die komplette Datenbank eingelesen und im RAM gehalten. Das müsste dann aber auch synchronisiert werden, weshalb entweder ich immer noch synchronisieren muss, oder ich lade "einfach" aus der Datenbank. Weiß da einer wie es mit der Geschwindigkeit?
Erläuternd dazu nutze ich aktuell VSTs um alle Bücher und die Exemplare anzuzeigen. Und sobald die Zahl in den 5-stelligen Bereich geht, merkt man das es etwas lahmt. Selbst wenn ich alles in den RAM lade braucht er immer noch ein Stückchen um zu suchen. Abgesehen davon macht aber das in den RAM laden mehrere Probleme die ich sonst relativ einfach umschiffen könnte.

MfG
Fabian

Wenn immer eine Verbindung zu einem Netwerk besteht ist natürlich ein zentrales DBMS besser. Wenn nicht wirst du um eine Synchronisation nicht herum kommen.
In diesem Fall würde ich ein DBMS einsetzen, das beides unterstützt. Das wäre sowohl bei FireBird wie auch MySQL möglich.
Das mit dem langsamen Zugriff erscheint mir eher ein Fehler im DB-Schema oder den Abfragen zu sein.

Moin,
das ist halt das Hauptproblem, dass ich aktuell nicht abschätzen kann, ob der Rechner wirklich 100% im Netzwerk sein wird. Und dann ist das einmal nicht und wetten das Programm wird gebraucht Deshalb war eine Idee, dass der DBMS auf den gleichen Rechner läuft. Und für Klassenräume die keine WLAN Abdeckung haben ginge würde ich dann den alten Weg nehmen. Aber in der Regel sollte überall Netzwerkzugriff sein, weshalb ich das für den einfacheren Weg halte.

Anderes Problem wäre: Wie verhindere ich, dass auf ein Datensatz gleichzeitig zugegriffen wird? Zum Beispiel: Am Hauptrechner wird gerade der Name des Schülers editiert, der genau in den Moment Bücher ausgeliehen bekommt: Irgendwo muss halt stehen, dass der Schüler gerade tabu ist (also Locks). Kann Firebird da was?

Und wegen den langsamen Zugriffen: Aktuell würde ich das so machen: In den VST für die Schüler stehen als Zeilen alle Personen drinnen (auch die Lehrer). Dann würde da stehen "in dieser Zeile ist die Person mit der ID x" und wenn er dann den Namen will, dann fragt er in der Datenbank den Namen der PersonID x nach.

MfG
Fabian

Zitat:

Zum Beispiel: Am Hauptrechner wird gerade der Name des Schülers editiert, der genau in den Moment Bücher ausgeliehen bekommt

Da die Berabeitung der Stammdaten etwas anderes ist, als eine Ausleihe sollte das kein Problem darstellen.
Sonst wäre da ein Fehler im DB-Schema.
Natürlicj könnte man für die Schüler, welche möglicherweise Ausleihen anstehen eine Sperre einrichten, ist aber imho nicht nötig.

Wennn irgendwie möglich würde ich bei so etwas ausschliesslich auf Online-Zugriff setzen. Das nachträgliche Synchronisieren von parallel geführten Datenbanken ist extrem aufwändig und fehleranfällig. Wir habe so etwas für einige kleine Teilbereiche unserer eigenen Datenbankapplikationen entwickelt, und es sind die Bereiche, die bei den Kunden den bei Weitem grössten Wartungsaufwand erfordern, weil doch immer wieder irgend eine Kleinigkeit schiefgeht.

Wobei das System einer Bibliotheksverwaltung hier relativ gut für so etwas geeignet ist.

Moin,
per Definition kann ja auch nichts schief gehen. Aber es ist relativ umständlich erst einen USB Stick vorzubereiten, da die Namen entschlüsselt werden (müssen), damit auch welche ohne Passwort damit arbeiten können. Und nachträglich muss der USB Stick wieder eingelesen werden.

So habe ich es erfolgreich geschafft, dass eine eingelesene Klasse verloren gegangen ist (die Daten wurden nicht richtig übertragen und dann überspielt). Außerdem ist man dann auch relativ mobil (sofern dort (W)LAN ist), nur müsste es dann eben auf den Rechner laufen. Ansonsten kann es leicht sein, dass die Netzwerkverbindung nicht mehr funktioniert, oder der Server mal heruntergefahren wird.

Und halt dann noch die Geschwindigkeit: Wenn ich 10.000 Datensätze einzeln abfrage, wie langsam ist dann die DB so ungefähr? Es war halt ziemlich langsam als wir die ersten Test mit der SQLite Datenbank gemachten haben. Wenn wir die Tabelle in einen Stück einlesen geht es halbwegs schnell und man muss nur einmal warten

MfG
Fabian

Du scheinst die Sache falsch anzugehen. Du benötigst 2 Datenbanken, welche du (teil-)sychron hälst. Im Notfall musst du ja beim "Abkoppel" einfach einen Kopie der Datenbank ziehen und bei der Rückkehr die ppar Datensätze, die sich geändert haben bzw. neu erstellt wurden zurückschreiben.
Warum musst du 10000 Datensätze abfragen?

Zitat:

Und halt dann noch die Geschwindigkeit: Wenn ich 10.000 Datensätze einzeln abfrage, wie langsam ist dann die DB so ungefähr?

...wieso mußt du 10000 Datensätze abfragen ?

Zitat von mkinzler:

Du scheinst die Sache falsch anzugehen. Du benötigst 2 Datenbanken, welche du (teil-)sychron hälst. Im Notfall musst du ja beim "Abkoppel" einfach einen Kopie der Datenbank ziehen und bei der Rückkehr die ppar Datensätze, die sich geändert haben bzw. neu erstellt wurden zurückschreiben.

Wie meinst du das?

Zitat von mkinzler:

Warum musst du 10000 Datensätze abfragen?

Wenn dort 10.000 Exemplare vorhanden sind die anzuzeigen sind Oder halt 900 - 1000 Schüler.

MfG
Fabian