DB in der Cloud

[Uwe Raabe]

Zitat von TigerLilly:

Ich glaube auch, dass es auch mit einem Db Server funktionieren müsste - wir verwenden auch für Einbenutzersysteme MSSQL Express - wenn die Services vorher/nachher gestartet/gestoppt werden.

Du kannst die Datenbank auch mit AUTO_CLOSE konfigurieren, dann kannst du dir das mit den Services sparen. Das sollte bei der Express-Version eigentlich schon von Haus aus aktiv sein.

[RSF]

Meine Erfahrungen
Lizenz der der DB überprüfen. Nicht jede kostenlose DB erlaubt den Einsatz von Middle-Ware.
Nachteil ist auch der ständige Abgleich Local mit der Cloud bei jeder Dateiänderung (Latenzzeit).
Bei instabiler Cloud-Verbindung kann es zu Fehlern in der DB-Konsistenz kommen. Unvollständigkeit, unterschiedliche Versionen die nicht gleich erkannt werden.

[Uwe Raabe]

Zitat von RSF:

Nachteil ist auch der ständige Abgleich Local mit der Cloud bei jeder Dateiänderung (Latenzzeit).

Bei Dropbox sollte das zumindest nicht passieren: https://www.dropbox.com/help/syncing...ds/file-in-use. Dort wird die Datei erst synchronisiert, wenn sie nicht mehr gesperrt ist. Für Google Drive kann ich auf die Schnelle leider keine entsprechende Information finden.

[RSF]

Zitat von Uwe Raabe:

Zitat von RSF:

Nachteil ist auch der ständige Abgleich Local mit der Cloud bei jeder Dateiänderung (Latenzzeit).

Bei Dropbox sollte das zumindest nicht passieren: https://www.dropbox.com/help/syncing...ds/file-in-use. Dort wird die Datei erst synchronisiert, wenn sie nicht mehr gesperrt ist. Für Google Drive kann ich auf die Schnelle leider keine entsprechende Information finden.

Das Problem ist nicht die Cloud (Dropbox und Co.) sondern die Architektur der DB. Nicht jede DB besteht nur aus einer Datei die gesperrt ist (bzw. bei mehreren gleichzeitig gesperrt sind).

[Bernhard Geyer]

Wenn man nur einen Read-Only-Datenstand haben will dann kann man DropBox und Co. verwenden.
Will man einen Datenstand haben der von mehreren externen Nutzern geändert werden kann, so ist ein Ansatz über DropBox und Co. nicht machbar.
Man hat entweder das Problem das zwei Nutzer fast Zeitgleich versuchen Daten zu ändern oder ein Nutze die Daten unverhältnismäßig lange sperrt (z.B. Offne zum Ändern und gehe Mittag).

Früher hätte man hier "einfach" auf die Replikationsmechanismen von MS SQL und Co. vertraut und seine Datenmodell so aufgebaut das es Replikation unterstützt.
Alternativ kann man eine Replikationsmechanismus selbst schreiben (was aber nicht trivial ist).

Heutzutage würde man (wenn man Online-Verbindung vorrausetzen kann) einfach eine MS SQL-Server instanz in der Cloud verwenden.
Das bietet z.B. MS mit Azure an.

[TigerLilly]

Zitat von Bernhard Geyer:

Will man einen Datenstand haben der von mehreren externen Nutzern geändert werden kann, so ist ein Ansatz über DropBox und Co. nicht machbar.

Können wir über das reden, was Sache ist? Es geht NICHT(!!) um Mehrbenutzer.

Zitat:

Bei welcher richtigen Datenbank sollte das passieren? Wenn sowas passieren kann ist es keine DBMS welche das ACID-Prinzip garantiert. Dann wäre die DB schrott.

Das Problem ist nicht die DB sondern die Synchronisation. Auch eine MSSQL-DB kann kaputtgehen, wenn sie auf Fileebene beschädigt wird. Aber ich habe dieses Problem weder bei OneDrive noch GoogleDrive je gehabt, egal, wie groß die Dateien waren.

Ad WebDav/Azure etc - warum so kompliziert? OneDrive/DropBox/GoogleDrive hat doch fast jeder.

Ich probier das jetzt mal aus + berichte dann:
- MSSQL-DB liegt direkt in meinem OneDrive-Order im Home-Office, der automatisch gesynct wird. Die DB hat AUTO_CLOSE gesetzt, weil ich hier keine Express Edition einsetze.
- Die DB ist ca 2 GB groß.
- Im Büro wird die - jetzt neu vorhandene DB - per Attach an meinen SQL Server gehängt.
- Beides sind SQL 2014 Server.

Stay tuned

[nahpets]

WebDav ist ein Netzwerkprotokoll und kann per Indy-Komponenten einfach ins Programm eingebunden werden. Genauso simple, wie HTTP per Indy.

Man braucht sich dann nicht darum kümmern, ob irgendwas automatisch synchronisiert wird. Es ist also, außer des eigenen Programmes, nichts erforderlich.

Anmeldename, Passwort und Pfad zur Datei (bei wem auch immer) ins Programm (natürlich konfigurierbar) und gut is.

[HolgerX]

Hmm...

Mal eine andere Sichtweise:
Datenbankdateien im Direktzugriff auf Clouds wie OneDrive/DropBox/GoogleDrive sind zu mindestens im Professionellen Bereich ein NOGO!

Wieso:
OneDrive/DropBox/GoogleDrive = USA

und damit datenschutzrechtlich ein massives Problem.

Da (normalerweise) die Daten in Datenbanken, von speziellen Konfigurationen weniger DB-Systeme abgesehen, unverschlüsselt gespeichert werden, dürfen solche Datenbanken, wenn sie personenbezogene Daten enthalten (hier reicht schon ein Name mit Adresse) nicht in einem Land abgelegt werden, wo der Datenschutz per Gesetz nicht besteht und jede Regierungsorganisation darauf zugreifen kann.

Das sollte eigentlich auch jeder für seine eigenen Daten berücksichtigen.
Aussagen wie 'Ich hab nichts zu verbergen' sieht die Person, um dessen personenbezogene Daten es sich handelt vielleicht anders!
Und spätestens, wenn du verreisen willst und dir die Einreise verweigert wird, weil dein Name in einer Datenbank eines potenziell Verdächtigen eingetragen war, kommt der Schrecken!!

Also ist bei Verwendung einer Cloud der direkte Online-Zugriff auf die Datenbank-Datei eigentlich schon nicht zu verwenden oder Du musst Dir von allen Personen eine entsprechende Datenschutzerklärung unterschreiben lassen, dessen Daten in der DB landen.

Somit bleibt nur die Option:
- Datenbankdateien komplett verschlüsselt ablegen
- Starten der App
- Download der Dateien
- Entschlüsseln
- lokal verbinden
- Beenden der App
- lokal trennen
- Verschlüsseln der DB-Dateien
- Hochladen.

( Nur so eine Sichtweise eines kleinen Paranoiker der lieber auf sicher geht)

[Bernhard Geyer]

Zitat von RSF:

Bei instabiler Cloud-Verbindung kann es zu Fehlern in der DB-Konsistenz kommen.

Bei welcher richtigen Datenbank sollte das passieren? Wenn sowas passieren kann ist es keine DBMS welche das ACID-Prinzip garantiert. Dann wäre die DB schrott.

Es könnte aber sein das die DB auf ihrer Ebene Konsistenz garantiert aber ein ungünstiges DB-Modell der Anwendung und fehlerhafte Implementierung auf Clientseite das Problem verursacht
(z.B. das @@IDENTITY, SCOPE_IDENTITY und IDENT_CURRENT-Problem beim MS SQL Server)

[nahpets]

Das es hier um eine Einzelplatzanwendung geht, die niemals von mehreren Benutztern gleichzeitig genutzt wird, ist eine Diskussion über die Mehrbenutzerfähigkeit eigentlich belanglos.

Für mich persönlich wäre der Lösungsansatz so:

T-Online-Mailadresse.
Man bekommt kostenfrei 25 GB Platz im Mediencenter zur Ablage beliebiger Dateien mit Zugriff über Webbrowser, Synchonisatzionssoftware und WebDav.
(Ginge auch bei Web.de, der Onlinespeicher dort ist aber "nur" 2 GB, Zugriffe über WebDav funktionieren ebenfalls.)
(Auf DropBox und GoogleDrive kann auch via WebDav zugegriffen werden.)

Dazu würd' ich mir ein Programm schreiben, das folgendermaßen vorgeht.

• Beim Programmstart wird die Datenbankdatei über WebDav auf den Client kopiert.
• Datenbankdatei in der Cloud löschen. (Man könnte sie dort auch umbenennen - als Sicherung des "Altbestandes".)
• Datenbank öffnen
• Dann wird beliebig mit der Datenbank gearbeitet.
• Beim Programmende Datenbank schließen.
• Die Datenbankdatei über WebDav in die Cloud kopieren. (Ggfls. beim Programmstart dort erstellte Sicherungskopie löschen.)
• Datenbankdatei auf dem Client löschen. (Man könnte sie hier auch umbenennen - als Sicherung des "Altbestandes".)

Die Cloud ist quasi die "Diskette", die ich mit von A nach B nehme, um entweder in A oder in B mit dem Disketteninhalt zu arbeiten. (Ok: Könnte auch ein USB-Stick oder 'n externe Festplatte ... sein)

Damit hat nur jeweils ein Nutzer die Möglichkeit, die Datenbank zu nutzen.

Das sollte mit SQLite und der Embbededversion von FireBird problemlos realisierbar sein.