DB in der Cloud

[TigerLilly]

Hat eigentlich schon jemand versucht, eine Datenbank in die DropBox oder auf OneDrive zu legen? Nicht für den gemeinsamen und gleichzeitigen Zugriff mehrerer User, sondern damit ein User von mehreren Standorten einen gemeinsamen Datenbestand hat.

Danke für jede Antwort.

[bnreimer42]

Das ist unmöglich für gemeinsamen Schreibzugriff, da der letzte gewinnt und Änderungen der anderen überschreibt zwischen Zeitpunkt des letzten Syncs und Schreibvorgang.

Das Funktioniert prima für Nur-Lesen Datenbanken für Stammdaten. Ich verwende dazu Firebird (embedded) mit einer ReadOnly Datenbank.

[mkinzler]

Ich würde dann aber trotzdem mit einer loaklen Datenbank arbeiten, welche dann bei Bedarf mit der neueren Version der Cloud überschrieben wird.

[TigerLilly]

Zitat:

Zitat von bnreimer42 (Beitrag 1384333)

Das ist unmöglich für gemeinsamen Schreibzugriff, da der letzte gewinnt und Änderungen der anderen überschreibt zwischen Zeitpunkt des letzten Syncs und Schreibvorgang.

Das Funktioniert prima für Nur-Lesen Datenbanken für Stammdaten. Ich verwende dazu Firebird (embedded) mit einer ReadOnly Datenbank.

Ich hab ja geschrieben: NICHT für Mehrbenutzer.

Szenario: PC im Büro und Laptop für unterwegs.

Zitat:

Ich würde dann aber trotzdem mit einer loaklen Datenbank arbeiten, welche dann bei Bedarf mit der neueren Version der Cloud überschrieben wird.

DropBox hab ich nie verwendet, aber bei Google Drive, OneDrive, Amazon hast du ja immer ein lokales Laufwerk, das per Cloud abgeglichen wird.Also eigentlich keine Notwendigkeit die DB doppelt zu halten.

Aber ich weiß halt nicht, wie zB ein MSSQL Server reagiert, wenn die MDF Datei von wem anderen geändert wurde. Außerdem müsste man da die Services ab/aufdrehen, damit das geht.

Ich glaub, ich probier das mal aus :-)

[mkinzler]

Du möchtest mit mehreren lokalen Serverinstanzen auf eine remote Datenbank auf einem Cloud-Speicher zugreifen?
Schon allein die Idee finde ich abstrus.
Bei Dropbox hat man einen lokalen Ordner, der mit einem Ordner in der Cloud synchronisiert wird. Lokale Änderungen würden zur Replikation führen. Deshalb würde ich die Datenbank nicht in einen Ordner legen, der sychronisiert wird. Ich würde die loakle Kopie manuell abgleichen (und nur in eine Richtung).

[TigerLilly]

Warum abstrus?

Sobald ich mein Programm starte, ist die DB für das Syncen gesperrt. Ist ja bei Word-Doks auch so. Beende ich mein Programm wird die lokale Änderung via DropBox/OneDrive zum 2ten Arbeitsplatz synchronisiert.
Starte ich am 2ten Arbeitsplatz meine Software habe ich alle Daten da.

Ist doch cool.

[mkinzler]

Und wenn einer die Datei löscht? Dann Sehen alle in die Röhre.

[TigerLilly]

Es geht um den Zugriff durch EINE(!) einzelne Person.

Wenn er löscht, sind die Daten weg. Ist aber eine andere Baustelle.

[jobo]

Soetwas mit einem einzigen User zu machen, ist sicher verlockend und wird in diversen Varianten sicher auch betrieben. Dabei würde ich zunächst Systeme wie sqlite o.ä. sehen, wo sich alles in einer Datei abspielt.

MSSQL oder vergleichbare Systeme wären nicht unbedingt meine Wahl für so ein Vorgehen, auch ein persönlicher Test würde mich nicht davon überzeugen, dass die Daten dauerhaft sicher hin und her bewegt werden.

Eigentlich will man ja hier wohl offline Fähigkeit eines fetten RDBMS und die gibt es nicht geschenkt.
Naheliegend wäre ja heutzutage erstmal eine online Verbindung des Client zur Serverdatenbank. Alles schön, solange WLAN da ist. An der Stelle liegt dann der Hase im Pfeffer und die Synchronisation, Replikation, .. beginnt.

Das alles einfach dateibasiert zu erschlagen, ist wie gesagt verlockend, aber ich sehe allein bei Dateigrößen, bei temporären Logdaten usw., bei der Frage, ob der Arbeitsplatzrechner wirklich aus dem System raus ist usw. sehr viele Fragezeichen.
Natürlich kann ich so diszipliniert sein, alles auszuknippsen, bevor ich den Rechner verlasse, aber ist sowas letztlich praxistauglich? Vielleicht für mich persönlich, aber wenn ich mir vorstelle soetwas einem geneigten Kollegen oder erst Recht einem ungeneigten Sachbearbeiter erklären zu müssen...

Ich denke, es ist kein Zufall, dass Sync-Lösungen für MSSQL & Co eben nicht einfach Dateien hinundherschieben, sondern Differenzmengen, auf welche Art auch immer.

[Uwe Raabe]

Zitat:

Zitat von TigerLilly (Beitrag 1384342)

Aber ich weiß halt nicht, wie zB ein MSSQL Server reagiert, wenn die MDF Datei von wem anderen geändert wurde. Außerdem müsste man da die Services ab/aufdrehen, damit das geht.

Grundsätzlich sollte das gehen wenn du nicht die reguläre Server-Version nimmst, sondern die embedded Version Microsoft SQL Server Compact. Dann ist sichergestellt, daß die Datenbankdatei beim Beenden des Programms auch nicht mehr in Benutzung ist.

[RSF]

Zitat:

Zitat von TigerLilly (Beitrag 1384324)

Hat eigentlich schon jemand versucht, eine Datenbank in die DropBox oder auf OneDrive zu legen? Nicht für den gemeinsamen und gleichzeitigen Zugriff mehrerer User, sondern damit ein User von mehreren Standorten einen gemeinsamen Datenbestand hat.

Danke für jede Antwort.

Ja, habe ich. Und ich kann bestätigen es geht wie beschrieben als Einzel-User! Läuft seit 2 Jahren problemlos.

[TigerLilly]

:shock: :thumb:

Welche DB, wenn ich fragen darf.

[RSF]

Darf (kann) ich aus rechtlichen Gründen (das kleingedruckte) nicht sagen. Auf jedem Fall embedded.8-)

[nahpets]

@TigerLilly

Was Du möchtest kann man doch eigentlich auch mit 'ner Datenbank auf 'nem USB-Stick vergleichen. Wer den Stick hat, hat die Datenbank.
Letztlich geht es doch darum, dass jeweils nur ein Nutzer auf eine Datenbank zugreifen kann, die sich auf 'nem externen Datenträger befindet (egal, ob jetzt irgend ein System automatisch Dateien repliziert oder man das händisch machen muss).

Dafür dürfte eigentlich alles geeignet sein, was in 'ner Embeddedversion genutzt werden kann.

Würd' es mal so sagen: FireBird, SQLite, entsprechende Version von MSSQL ..., auch 'ne Access-MDB müsste gehen.

Und wenn man das für sich selbst macht, hat man ja letztlich auch nur selbst auf die Datei Zugriff (egal wo sie nun liegt, Dropbox, OneDrive, über WebDav im Mediencenter zur T-Online-Mailadresse ..., dito. Onlinespeicher bei web.de ...).

[TigerLilly]

Ja, genau.
Ich bin immer wieder von Nutzern unserer Software darauf angesprochen worden, wie cool es wäre, wenn die Daten "in der Cloud" liegen würden. Und das wäre so eigentlich eine elegante Möglichkeit.

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.

[Uwe Raabe]

Zitat:

Zitat von TigerLilly (Beitrag 1384394)

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:-D
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:

Zitat von RSF (Beitrag 1384402)

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:

Zitat von Uwe Raabe (Beitrag 1384403)

Zitat:

Zitat von RSF (Beitrag 1384402)

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.

[Bernhard Geyer]

Zitat:

Zitat von RSF (Beitrag 1384402)

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:

Zitat von Bernhard Geyer (Beitrag 1384409)

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:

Zitat von nahpets (Beitrag 1384447)

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:

Zitat von HolgerX (Beitrag 1384449)

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

[HolgerX]

Hmm..

Zitat:

Zitat von jobo (Beitrag 1384465)

Zitat:

Zitat von HolgerX (Beitrag 1384449)

( 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)!

Oje, dann können ja bald alle mit Insektennamen nicht mehr verreisen! ;)
( Mr. Biene führt einen mit Gift versehne Stichwaffe mit sich und wird deshalb als 'Gefährder' betrachtet! )

Zitat:

Zitat von vagtler (Beitrag 1384467)

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.

Da man leider immer wieder sieht, dass von eventuellen Zusagen und auch Zertifikaten (erstellt durch irgendwelche Prüfunternehmen) nichts das Papier Wert ist, wo es drauf gedruckt wurde, bin ich immer noch Skeptisch!
Viele der Cloud-Unternehmen preisen ihre 'Server in EU' oder 'Datenschutz nach EU' groß an, jedoch sitzen sie mit Ihren Mitarbeitern immer noch in den USA und unterliegen den dortigen Gesetzen und auch wenn sie Partnerschaften mit z.B. T-System angeben, brauchen Sie immer noch Admin-Zugänge zur Verwaltung. In der Fachpresse (nicht BILD ;) ) wurden die Regelungen und Datenschutzerklärungen mit Ihren Zertifikaten nach ISO/DSGVO/.. mal durchleuchtet und selbst einige Deutsche Cloud-Anbieter sind durchgefallen. Viele der Zertifikate sind so schwammig, nichtbindend und Lückenhaft, dass sie unbrauchbar sind!

Das Fazit aller dieser Reportagen war: Nur mit Verschlüsselung von Daten VOR dem Hochladen in die Cloud kann der Datenschutz annähernd sicher gestellt werden!

Zitat:

Zitat von jobo (Beitrag 1384465)

Und es war gar nicht das Thema!

Irgendwie doch, wenn man meine Sichtweise zugrunde legt, sollte man nicht nur weil es möglich ist, eine Datenbank direkt auf einer Cloud verwenden ohne sicherzustellen, dass die Daten darin verschlüsselt sind.
Bereits auch von anderen wurde die Version des 'Herunterladens und lokalem Verwenden' ja bereits gepostet, ich habe nur das 'Verschlüsseln' hinzugefügt, um auch das Thema 'DB in Cloud' von einer anderen Sichtweise heran zu gehen.

Ausgenommen würden nur Firmen-Intere bzw. selbst gehostete Cloud-Server machen, welche entsprechend abgesichert werden.

(Wie geschrieben: 'Nur eine andere Sichtweise' ;) )