Online-Applikation (PHP, MySQL) offline nutzen

[Roger]

hallo!

Eine Applikation im Extranet, basierend auf PHP und MySQL, bedienbar durch einen Browser soll jetzt offline verfügbar gemacht werden.

Sie soll jetzt mit einem tragbaren Gerät (Laptop, PDA) bedient werden, an Orten, wo es kein Internet gibt. Die Daten sollen später synchronisiert werden.

Wie kann so etwas umgesetzt werden? Was ist der beste Weg?
(Bitte kein XAMP vorschlagen, WAMP ist völlig ausreichend ;)

Problem bei der Applikation, sie wird mit Daten aus der Datenbank beliefert. Wenn Sie nun offline betrieben wird, dann ist nat. keine Kommunikation mit dem Online-Server möglich. Ein lokales WAMP scheint mir momentan noch am sinnvollsten. Allerdings ist die DB ziemlich umfangreich und die Prozessorleistung sollte man auch nicht vernachlässigen (ziemliche viele for-Schleifen!).
Man könnte pro Arbeitsgang nur die notwendigen Daten in die lokale DB holen und die dann bearbeiten. Aber dann kann man doch gleich ne Excel-Tabelle erzeugen lassen, in die man die Daten ein trägt... (btw: will der Kunde nicht ;)

Gibt es noch andere Möglichkeiten, die in Betracht zu ziehen wären (z.B. eigenständige Java-Applikation, Cookie / Flash Cookie), zunächst unabhängig von den Kosten?

Ich habe doch neulich erst was gelesen, dass man Google-Anwendungen jetzt auch offline betreiben kann?

gruß.
roger.

[EKKi]

Mahlzeit,

Wie kann so etwas umgesetzt werden? Was ist der beste Weg?

Naja ... ne entsprechende MySQL-Datenbank (samt Inhalt), nen Webserver und nen PHP-Interpreter auf den Laptop - also war WAMP bzw. XAMP schon ne ganz gute Idee.

Gibt es noch andere Möglichkeiten, die in Betracht zu ziehen wären (z.B. eigenständige Java-Applikation, Cookie / Flash Cookie), zunächst unabhängig von den Kosten?

Sicher könnte man sich die Mühe machen, eine vollkommen neue Oberfläche für die Datenbank zu bauen, vielleicht gar die Datenbank gegen was anderes auszutauschen oder so ... aber war nicht grad die Frage bzw. Anforderung, dass die Extranet-Web-Anwendung einfach (ohne Änderungen) auf nen Laptop portiert werden soll? Ohne Oberflächenänderungen (und dadurch ggf. "Schulungsaufwand" usw.)?

MfG,
EKKi

[Roger]

hallo!

Sicher könnte man sich die Mühe machen, eine vollkommen neue Oberfläche für die Datenbank zu bauen, vielleicht gar die Datenbank gegen was anderes auszutauschen oder so ... aber war nicht grad die Frage bzw. Anforderung, dass die Extranet-Web-Anwendung einfach (ohne Änderungen) auf nen Laptop portiert werden soll? Ohne Oberflächenänderungen (und dadurch ggf. "Schulungsaufwand" usw.)?

Genau. Je weniger an der Oberfläche geändert wird, umso geringer der "ist ja alles neu-Effekt". Schulungskosten etc. würden sich dann auch minimieren. Problem wird nur sein, das ganze auf nem PDA zum laufen zu bekommen. Aber andererseits müssen halt auch abstriche gemacht werden.

gruß.
roger.

[EKKi]

Mahlzeit,

Genau. Je weniger an der Oberfläche geändert wird, umso geringer der "ist ja alles neu-Effekt". Schulungskosten etc. würden sich dann auch minimieren. Problem wird nur sein, das ganze auf nem PDA zum laufen zu bekommen. Aber andererseits müssen halt auch abstriche gemacht werden.

Hihi, auf nem PDA? Na, da bin ich ja mal SEHR gespannt ... manchmal muss man sich halt einfach zwischen "Entweder" und "Oder" entscheiden - eierlegende Wollmilchsäue (oder datenbankende Webserver-PDAs) sind halt seeehhhr, seeehhhr selten.

MfG,
EKKi

[Sven Rautenberg]

Moin!

Genau. Je weniger an der Oberfläche geändert wird, umso geringer der "ist ja alles neu-Effekt". Schulungskosten etc. würden sich dann auch minimieren. Problem wird nur sein, das ganze auf nem PDA zum laufen zu bekommen. Aber andererseits müssen halt auch abstriche gemacht werden.

Hihi, auf nem PDA? Na, da bin ich ja mal SEHR gespannt ... manchmal muss man sich halt einfach zwischen "Entweder" und "Oder" entscheiden - eierlegende Wollmilchsäue (oder datenbankende Webserver-PDAs) sind halt seeehhhr, seeehhhr selten.

Oh ja, ich hab' noch keinen PDA erlebt, der auch nur im geringsten die notwendige Bildschirmauflösung hätte, um mit einem Laptop zu konkurrieren. Das höchstauflösende Display, das mir bislang vor die Augen kam, hatte 640*480 Pixel bei 200irgendwas dpi, und gehörte zum OpenMoko. Das wäre allerdings auch der einzige PDA, bei dem ich mir vorstellen kann, dass man darauf einen Webserver, PHP und eine Datenbank zum Laufen kriegt, weil er ausreichend mit Speicher bestückt ist.

Alle anderen Geräte dürften allein schon wegen des Displays und der grundsätzlich ganz anderen Eingabemöglichkeit eine Anpassung erfordern.

Dann der nächste Punkt: Synchronisation. Es ist extrem aufwendig, eine nach allen Regeln der Kunst wirkende Synchronisation zwischen zwei identischen Datenbanken durchzuführen. Es wird immer das Problem geben können, dass der gleiche Datensatz in beiden Datenbanken unterschiedlich geändert wurde. Alleine der Aufwand, das zu entdecken, ist schon sehr groß und verursacht einiges an Extradatenmenge.

Angesichts der Tatsache, dass es hier offenbar "nur" um mobile Datenersterfassung mit PDA geht, dürfte es deutlich simpler sein, dafür eine spezialisierte Applikation zu schreiben, die ihre Daten dann einfach nur der Datenbank übergibt - und zwar genau so, als würde man sie dort über den sonst üblichen Weg erstmalig eingeben.

Und wenn's darüberhinaus noch notwendig ist, könnte man den restlichen Datenbestand als "nur lesen" auf dem PDA in einem speicherkomprimierten Format verfügbar machen.

- Sven Rautenberg

[Frank (no reg)]

Hi,

naja, mit WAMP auf einem PDA wirst du vielleicht nicht wirklich weit kommen?

Eine lokale Datenhaltung auf Basis XML wäre da universeller. Gepaart mit einer platformspezifischen Client-Anwendung (Java, .net).

Find heraus, welche Daten du "generell" zum lokalen Betrieb benötigst und welche davon mehr oder statisch sind und welche Daten zu synchonisieren wären.

Wie sollte denn die Synchronisation ablaufen?

Ciao, Frank

[Roger]

hallo!

Wie sollte denn die Synchronisation ablaufen?

Ist noch nichts in Planung. Ich versuche jetzt erst mal die Techniken abzuwägen, wie die Applikation betrieben werden kann. Natürlich auch in Hinblick auf die Synchronisation.

Letztendlich sollen im ersten Schritt nur neue Objekte angelegt werden (pro Objekt gibt es ne Menge Textfelder, Radiobuttons und Checkboxes und auch 2 Select-Boxen, deren Inhalt sich aber kaum ändert). Und diese Objekte sollen dann (meinetwegen per Click) mit denen in der DB abgeglichen werden. (Wobei das wohl auch ein dicker Brocken ist...)

gruß.
roger.

[Frank (no reg)]

Beschäftige dich vielleicht besser zuerst nicht mit "der Technik", sondern mit dem Prozess. Wenn du diesen nicht hinbekommst, dann kannst du noch so viel Technik dahinterpacken, es wird höchstwahrscheinlich einfach nicht "funzen".

Für die Rückreplikation solltest du dann Regeln definieren (gleichzeitigkeit, vorrang nach Änderungsdatum, ....) wie selbige auf Entitätsbasis ablaufen sollte. Technologien für soetwas gibt es dann recht viele, "passende" vielleicht etwas weniger.

Ich sehe da auf der Design- bzw. Modellierungsseite wesentlich mehr Schwierigkeit und Aufwand als letztendlich auf der Implementierungsseite. Eine rich/smart/embedded Client Software zur Datenerfassung und Logik für die Synchronisation ist recht schnell geschrieben. Aber alles steht und fällt mit der Bekanntheit der Regeln.

Ciao, Frank

[bleicher]

Grüße,
minimalfall "bambalam" oder änliches nehmen ich an - das dürfte am kompatibelsten sein. oberfläche wäre dann secundär
MFG
bleicher

[Cybaer]

Hi,

Ich habe doch neulich erst was gelesen, dass man Google-Anwendungen jetzt auch offline betreiben kann?

Ja, Google Gears ist eine JS-API mit einer kleinen SQLite-Datenbank und Cache. Ist der Client offline, so bedient der Client sich im Cache und der Datenbank, ist er online, so werden die Daten synchronisiert.

Gruß, Cybaer