DB in der Cloud

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

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