Ist SQLite DB Datei vom Webserver lesen möglich?

[GPI]

[...] Ferner wäre die Installation eines ODBC Treibers nicht notwendig. [...]

Für SQLite benötigst Du keinen ODBC-Treiber.

Wenn er auf MySQL übergeht, dann wird er nicht drum herumkommen

@ MenschMarkus
Direkt nein, aber das Entpacken geht innerhalb von sekunden. Downloaden, entpacken, 7z löschen. mit GetHTTPHeader() kannst du den Header der 7z-Datei auf den Server auslesen. Wie gesagt, nicht vergessen, da gibt es noch eine Zweite Datei mit der Versionsnummer der Datenbank. Solange die sich nicht ändert ist kein Download nötig.

Ich weis allerdings nicht, wie sicher es ist, eine serverseitige SQL-Datenbank frei zugänglich zu machen. Die meisten Webhoster blockieren das und erlauben nur ein Zugriff von lokalen Server aus - also von Web-Software.

[mhs]

Ich weis allerdings nicht, wie sicher es ist, eine serverseitige SQL-Datenbank frei zugänglich zu machen. Die meisten Webhoster blockieren das und erlauben nur ein Zugriff von lokalen Server aus - also von Web-Software.

Kommt ganz auf den Webhoster an. Je nach Webhoster und Paket ist das überhaupt kein Problem, oft muss der Zugriff von außerhalb allerdings in den DB Einstellungen explizit aktiviert werden.

[TroaX]

Kommt ganz auf den Webhoster an. Je nach Webhoster und Paket ist das überhaupt kein Problem, oft muss der Zugriff von außerhalb allerdings in den DB Einstellungen explizit aktiviert werden.

Bei Webspace-Paketen ist das aber meist nicht möglich, da die Benutzereinstellungen im DBMS gesperrt sind. Die Benutzer werden meist beim Hoster direkt im eigenen Webinterface unique mit einer Datenbank verknüpft, die meistens nur Zugriff von 127.0.0.0 und localhost erlauben. Wer also aus diesem Environment des klassischen Webhostings ausbrechen will, um zum Beispiel Webservices für Applikationen bereitzustellen, der wird sich bei den meisten klassischen Webspace's auf ein Interface über den Webserver den Zugang verschaffen. Aber gerade das ist definitiv deutlich sicherer. Denn die meisten Webspaceanbieter bieten meines Kenntnisstandes nach keine SSL-Verschlüssellung für die MySQL-Datenbank an (obwohl es sie gibt), da sie eh nur die Verbindung serverintern zulassen. SSL-Unterstützung bietet hingegen jeder kostenpflichtige Webspace für das HTTP-Protokoll an (nur meist eben ohne Zertifikat, wobei sich das ja jetzt dank freier Zertifikate ändern wird). Für das Interface (z.B. in PHP) kann man dann genau dieses nutzen, um von Client und Server die Daten verschlüsselt zu übertragen. Bei einer Direktverbindung zum DBMS hingegen ist das schon etwas schwieriger.

Entweder ein HTTP-Interface oder auf einen VServer wechseln und dort das DBMS selbst installieren und konfigurieren. Denn selbst wenn ein Hoster die direktverbindung von extern unterstützt, müsste noch sichergestellt werden, das diese Verbindung verschlüsselt ist. Wenn nicht, dann sollte man das vielleicht doch lassen.

[GPI]

Entweder ein HTTP-Interface oder auf einen VServer wechseln

Dabei bedenken, das VServer alles andere als Kinderspiele sind. Da kann man schnell was verkehrt machen und dann kann es sogar kräftig teuer werden. Gab mal eine News, das welche einen Server aufgestellt haben, der durch Fehler gehackt wurde und anschließend für anderes Missbraucht wurde. Das große Problem: Dabei entstand massiver Traffic und die Kosten des Servers haben sich nach den Traffic gerichtet.

VServer ist wirklich was nur für Leute die Ahnung haben und auch die Zeit haben, die zu pflegen. Wenn ich die Eingangsfrage betrachte, würde ich das hier nicht wirklich empfehlen.

[NicTheQuick]

Entweder ein HTTP-Interface oder auf einen VServer wechseln

Dabei bedenken, das VServer alles andere als Kinderspiele sind. Da kann man schnell was verkehrt machen und dann kann es sogar kräftig teuer werden. Gab mal eine News, das welche einen Server aufgestellt haben, der durch Fehler gehackt wurde und anschließend für anderes Missbraucht wurde. Das große Problem: Dabei entstand massiver Traffic und die Kosten des Servers haben sich nach den Traffic gerichtet.

VServer ist wirklich was nur für Leute die Ahnung haben und auch die Zeit haben, die zu pflegen. Wenn ich die Eingangsfrage betrachte, würde ich das hier nicht wirklich empfehlen.

Bei Serverloft oder Strato kriegst du sehr günstig Virtuelle Server mit unlimitiertem Traffic. Da braucht man sich dann keine Gedanken zu machen, da die Kosten fix sind. Mit Hackern hatte ich auch schon zu tun, und hab sie bisher immer erfolgreich wieder aus unserem System vertreiben können. Mit aktuellen Linuxen hatte ich aber nie Probleme. Nur mit uralten, auf denen noch ältere Software lief, die den Hackern den eigentlichen Zugriff gewährte.

[MenschMarkus]

@Kiffi

zuvor eine Frage: Verfügst Du über einen eigenen Webserver, bzw. erlaubt Dein Webhoster Dir, eigene CGIs auf Deinem Webspace laufen zu lassen? Denn nur dann wäre (Fast-)CGI für Dich interessant.

In den Account Einstellungen steht, CGI wird unterstützt, wie auch PHP, PYTHON,PERL,ASP

Was mir noch in Deinem ersten Posting aufgefallen ist:
MenschMarkus hat geschrieben:

[...] Ferner wäre die Installation eines ODBC Treibers nicht notwendig. [...]

Für SQLite benötigst Du keinen ODBC-Treiber.

Naja, das hatte ich ja auch so gemeint, es ist KEIN ODBC Treiber notwendig

In der Zwischenzeit habe ich mich dennoch mal mit der Installation des ODBC Treibers auseinandergesetzt. Da ich unter Windows verhindern möchte, dass der DAU das via des MSI Insttallationspaketes machen soll, war mir wichtig, dass ich eine SilentInstallation durchführen kann. Mittlerweile unter Zuhilfenahme einer VM zum Testen ist mir das auch gelungen. Dennoch bin ich sehr an einem eigenen CGI interessiert. ODBC wäre Plan B wenn sich Plan A, also (Fast)CGI, nicht verwirklichen lässt.

@Alle
Danke für Eure Posts. Alle beinhalten für mich interessante Informationen. (siehe footer )
Weiter so

[GPI]

Ich würde vermutlich eine PHP-Datei schreiben, die mir einfach die Informationen liefert.
Dazu müsste man jetzt wissen, wie die Datenbank aussieht und was du abfrägst. Das dürfte (wenn man die Übergaben entsprechend behandelt), die einfachste und sicherste Möglichkeit sein.

p.s.: Komm da bitte nicht auf die Idee eine SQL-Abfragestring übertragen zu wollen - das geht nur ins Auge

[MenschMarkus]

@GPI

Ich würde vermutlich eine PHP-Datei schreiben, die mir einfach die Informationen liefert.

Danke erst einmal für die Anregung. Ziel ist es aber die SQLite Datei direkt anzusprechen und zum Einlesen der Daten auf einem AP zu öffnen. Alles Andere, wie schon vorgeschlagen zu packen und herunter zu laden wird ja schon gemacht. Davon möchte ich möglichst weg, da die Datenbank Zentral und nicht Lokal gehalten werden soll. Lokal existiert die Datenbank dann nur noch im Arbeitsspeicher solange das Programm läuft. Mit einem PHP Skript muss ich die Daten wiederum erste einmal aus der SQLite DB Datei herausziehen, wobei ich noch nicht weiß ob ich mit PHP überhaupt auf die von PB erstellte SQLite DB zugreifen kann, um diese auf Client Seite wieder in eine virtuelle DB zu schreiben. Das scheint mir doch im Vergleich zu, ich greife via OpenDatabase() direkt auf meine SQLite DB Datei auf meinem Serverplatz zu, recht umständlich zu sein. Aber OK, umständlich bedeutet nicht unbedingt auch gleich schlechter.

Gruß
MenschMarkus

[TroaX]

Du gehst da mit einer völlig falschen Denkweise ran. Es ist im Bezug auf Sicherheit absolut bedenklich, die Datenbank über Download einzeln zu beziehen. Und vor allem bringt es nichts, wenn 2 Leute die Datenbank zur selben Zeit brauchen. So bekommst du keine Konsistenz in deinen Datenbestand. PHP kann mittels PDO problemlos auf SQLite Datenbanken zugreifen. Mit welcher Software diese erstellt wurden, spielt dabei keinen Unterschied. SQLite ist SQLite.

Damit die Konsistenz der Datenbank erhalten bleibt, muss sich Serverseitig eine Software um die Datenbank kümmern (z.B. PHP). Denn dadurch hast du eine Schnittstelle zwischen Client und Datenbank, die jederzeit jede Aktualisierung an jeden Client übermitteln kann. Ansonsten führt es das Prinzip einer globalen Verfügbarkeit der Datenbank völlig in die Absurdität. Du brauchst die Datenbank so nicht in den RAM laden. Der PHP Interpreter erledigt das ganze für dich. Im übrigen eignet sich eine MySQL-Datenbank deutlich besser dafür, da du mit PHP und PDO eine Permanente Verbindung zur Datenbank aufbauen kannst. Außerdem ist MySQL allein schon wegen dem SQL-Umfang und dessen Optimierungen deutlich schneller.

[NicTheQuick]

Aus guten Gründen macht es niemand so, wie du das vorhast. Und eine Datei direkt über HTTP/FTP zu öffnen, geht sowieso nicht. Selbst über WebDAV geht das nicht direkt, das wird auch vorher gecached, was aber das Betriebssystem für dich regelt.

Entweder man schreibt sich eine Serverseitige API, wie z.B. das genannte PHP-Skript, oder man schreibt sich seinen eigenen Server-Dienst, also ein Programm das ständig auf dem Server läuft und über einen bestimmten Port ansprechbar ist. Serverseitig nutzt man natürlich nicht SQLite, sondern was schnelles skalierbares, z.B. MySQL.

Warum bestehst du darauf, die SQLite-Datei direkt anzusprechen? Weil du dein vorhandenes Programm dann nicht mehr groß ändern musst? Oder gibt es sinnvollere Gründe dafür?