DB in der Cloud

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

[IBExpert]

Wenn das ein Einzelplatzanwendung ist, wird das sicherlich auch mit Firebird embedded gehen, aber wie groß soll die DB denn sein?
Hol dir sonst doch einfach für ca 10 € im Monat einen virtuellen Server bei hosteurope (gibt es für den Preis auch mit Windows
und 100GB HDD/2GB RAM und ist für simple Firebird Anwendungen gar nicht mal so schlecht) und lass den User per Rdp da drauf
arbeiten. Dann fällt der Kopierquatsch weg, wenn die db größer wird.

Ist aber nur dann sinnvoll, wenn unterwegs auch Onlineverbindung läuft.

Ansonsten lass die DB doch einfach auf dem Laptop und wenn der eine User im Office ist, kann der PC ja auch auf der Laptop
DB arbeiten, zB mit FB, sofern der Laptop im Netz ist und eingeschaltet ist.

[nahpets]

TigerLilly schrieb:

Zitat:

Ich bin immer wieder von Nutzern unserer Software darauf angesprochen worden ...

Das hieße dann: Jeder Nutzer, der für sich die Einzelplatzsoftware mal im Büro am PC und mal unterweges mit dem Laptop nutzen möchte, müsste dann

Zitat:

für ca 10 € im Monat einen virtuellen Server bei hosteurope ...

für sich einrichten und bei der Implemetierung begibt man sich dann auch in Abhängigkeiten, die man an den Nutzer ggfls. "weitergibt".

WebDav und diverse Anbieter: Man hat die Möglichkeit die jeweilige Synchronisationssoftware zu nutzen oder die WebDAV-Verbindung individuell im Programm zu konfigurieren. Dann ist's egal, bei welchem Anbieter der Nutzer seine Datenbankdatei "in die Cloud schiebt".

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

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

[vagtler]

An dieser Stelle sei der Vollständigkeit halber kurz erwähnt, dass gerade die Dienste großer Cloud-Anbieter wie Google, Microsoft und Amazon durchaus DSGVO-Compliant betrieben werden können.