DB in der Cloud

[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.

[Bernhard Geyer]

Zitat von 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.

Dieses "simple und einfache" WebDav hat uns bei einen Kunden bei den wir darauf gesetzt haben viele Probleme bereitet.
Bei einen neuen Kunden mit ähnlichen/gleichen Anforderungen werden wird definitiv nicht mehr auf WebDav setzen sondern http(s) bzw. ftp einsetzen.

[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)

[jobo]

Zitat von HolgerX:

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

Stell Dich nicht so an, es ist sicher nur eine Datenbank, mit Fotos und Texten zur privaten Insektensammlung. Völlig harmlos im Datensschutzsinne (außer für Insekten)!
Und es war gar nicht das Thema!

Ja und DSGVO bzw, BDSG-neu kommt ja erst nächstes Jahr.

[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)