Portable Datenbank

[johny7]

Moin allerseits,

ich suche nach einer protablen Lösung für's USB-Stick. Ich will nämlich eine Anwendung zum Katalogisieren und Verwalten von Dateien. Mir schwebt da am Besten eine Datenbank vor, in die ich die Dateien einspeisen und die ich dann mit versch. Attributen versehen und auf die Art mit anderen Tabellen verknüpfen kann. Im Endeffekt soll es eine Anwendung werden, wo in versch. Modi die Dateien ausgewählt und ausgegeben werden.
Ich will diesen USB-Stick an meine "Kunden" geben, die dann nur noch rein damit, und es erscheint ein Dialog, mit dem sie dann Schritt für Schritt die Auswahl eingrenzen und die Dateien dann ausgespuckt bekommen.
Das soll aber mit der Basiskonfiguration von Windows (ab 98 oder XP) funktionieren, d.h. ohne vorherige Installation oder so etwas.
Wie ich das mit MS Access realisieren würde, weiß ich. Aber das Problem ist, ich kann nicht voraussetzen, dass meine Kunden Access installiert haben.

Ich brauche also

• Portabilität (d.h. ohne Installation sofort und von USB-Stick)
• Daten werden nur auf USB-Stick angelegt
• Unterstützung von alternativen BS wäre auch nicht verkehrt

Wenn ich die Datenbank dann auch noch (nach Eingabe des Passworts) portabel auf dem Stick bearbeiten kann, umso besser.

Noch besser wäre, wenn ich auch die Dialogführung von meiner Datenbank abhängig machen kann. Dann könnte ich nämlich ein Software-Update per Aktualisierung der Datenbank durchführen.

Grüße, JN

[fastix®]

Moin!

Moin allerseits,

ich suche nach einer protablen Lösung für's USB-Stick.

Wieviel willst oder kannst Du dafür ausgeben?

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[bleicher]

Grüße,
ich weiss ncih tob es deinen ansprüchen genügt, aber es gibt "OpenOffice base" - sicher auch als portable version.
MFG
bleicher

[johny7]

Moin allerseits,

ich danke euch für eure Antworten.

Mit einer Scriptsprache ist es kein großes Problem, große Teile des Programmcodes in der Datenbank zu halten. Ob das clever oder sinnvoll ist, ist eine andere Frage.

Hast du einen konkreten Lösungsvorschlag? Eine Lösung per Internet wäre am einfachsten. Mit PHP und MySQL ist es ja nicht schwer, so eine Anwendung zu realisieren. Aber meine Kunden wollen aus div. Gründen nicht übers Netz mit mir agieren. Gibt es eine andere Möglichkeit? Ein konkretes Beispiel?

Grüße,
ich weiss ncih tob es deinen ansprüchen genügt, aber es gibt "OpenOffice base" - sicher auch als portable version.

Habe ich ausprobiert. Funktioniert es auch, wenn mein Client-PC z.B. keine Java Runtime hat?
Kann ich in die Datenbank von Base auch Dateien speichern? Per Datei-Upload-Dialog?
Kann man die auch so wie MS Access aufrufen, dass sofort ein Dialog kommt und nicht die Entwurfs-Ansicht? In Access kann man glaub ich sogar den Zugriff auf die Entwurfs-Ansicht per Passwort verschlüsseln.

Grüße, JN

[Alexander (HH)]

Moin Moin!

Mit einer Scriptsprache ist es kein großes Problem, große Teile des Programmcodes in der Datenbank zu halten. Ob das clever oder sinnvoll ist, ist eine andere Frage.
Hast du einen konkreten Lösungsvorschlag? Eine Lösung per Internet wäre am einfachsten. Mit PHP und MySQL ist es ja nicht schwer, so eine Anwendung zu realisieren.

Grundprinzip: select aus einer Tabelle, abhängig vom gerade benötigten Code, String-eval, um aus dem String aus der Datenbank Programmcode im Arbeitsspeicher zu machen, Routinen aufrufen. In Perl z.B. mit einem Hook in @INC.

Aber wozu das? Wenn Du schon Updates verteilst, dann kannst Du auch den Programmcode austauschen statt in der DB herumzueiern.

Aber meine Kunden wollen aus div. Gründen nicht übers Netz mit mir agieren.

Muß / will ich das verstehen? Wenn sie Policies haben, die verbieten, das Netz zu nutzen, warum lassen sie sich dann auf das viel gefährlichere Spiel ein, Dir über den USB-Stick direkten Zugriff auf den Rechner zu gewähren?

Gibt es eine andere Möglichkeit? Ein konkretes Beispiel?

Wofür? Zugriff auf Deine Daten? Entweder lieferst Du sie komplett samt Abfrage-Werkzeug auf einem Medium Deiner Wahl (bzw. nach Kundenwunsch) aus, oder Du bietest einen Zugang über das Netz, oder Du machst ein Callcenter auf, wo Deine Telefonsklaven die Anfragen im Auftrag des Kunden in Deine DB hacken.

ich weiss ncih tob es deinen ansprüchen genügt, aber es gibt "OpenOffice base" - sicher auch als portable version.
Habe ich ausprobiert. Funktioniert es auch, wenn mein Client-PC z.B. keine Java Runtime hat?

Ja, OOO läuft auch ohne JRE, mit minimalen Einschränkungen. (Wobei ich zugeben muß, dass ich den DB-Teil von OOO noch nicht wirklich ohne JRE ausprobiert habe.) Was spricht dagegen, selbst mal zu experimentieren? Ein alter PC oder VMWare, frische OS-Installation, Stick / ISO-Image rein und probieren, ob alles funktioniert.

Kann ich in die Datenbank von Base auch Dateien speichern? Per Datei-Upload-Dialog?

Es gibt bei lokalen Anwendungen keinen Upload. Du kannst vielleicht eigenen Programmcode dazu überreden, eine Datei im Binärmodus zu öffnen, den Inhalt zu lesen, und in ein geeignet großes Datenbank-Feld (BLOB) zu schreiben. Oder entsprechend anders herum aus der DB lesen und in eine Datei schreiben.

Kann man die auch so wie MS Access aufrufen, dass sofort ein Dialog kommt und nicht die Entwurfs-Ansicht?

Das steht sicherlich in der Dokumentation bzw. Online-Hilfe von OOO.

In Access kann man glaub ich sogar den Zugriff auf die Entwurfs-Ansicht per Passwort verschlüsseln.

Was nicht wirklich was bringt, wenn der Passwort-Schutz trivial zu knacken ist. Die alten MS-Office-Versionen waren da sehr anfällig, wie das bei den neuen aussieht, weiß ich nicht.

Ich sehe hier ein großes Problem: Du traust Deinem Kunden nicht, denn sonst würdest Du nicht so verzweifelt verhindern wollen, dass er ungehindert Deine Daten einsieht. Und Dein Kunde traut Dir auch nicht, denn sonst würde er kein Problem mit einer DB-Abfrage über das Internet haben, und ggf. entsprechend Policies lockern.

Arbeite erstmal an diesem Problem, dann kannst Du Dich, zusammen mit dem Kunden, immer noch zwischen einer rein lokalen Anwendung mit regelmäßigen Updates per CD/Stick, reiner Web-Anwendung mit stets aktuellen Daten, und einem Mittelding -- z.B. lokale Anwendung mit Auto-Update über das Netz, z.B. Browser-gestützter Anwendung mit Zugriffsprivilegien auf das lokale System (z.B. signierte Applets) -- entscheiden.

Warum brauchst Du überhaupt Dateien UND eine Datenbank? Was genau willst Du bauen?

eine Anwendung zum Katalogisieren und Verwalten von Dateien

ist nicht sonderlich spezifisch. Was für Dateien sind das? Wieso müssen sie in einen Katalog? Was soll an ihnen verwaltet werden?

Alexander

[johny7]

Moin allerseits,

»» Grundprinzip: select aus einer Tabelle, abhängig vom gerade benötigten Code, String-eval, um aus dem String aus der Datenbank Programmcode im Arbeitsspeicher zu machen, Routinen aufrufen. In Perl z.B. mit einem Hook in @INC.
Das Grundprinzip war mir klar...

»» Aber wozu das? Wenn Du schon Updates verteilst, dann kannst Du auch den Programmcode austauschen statt in der DB herumzueiern.
Da hast du Recht.

»» »» Aber meine Kunden wollen aus div. Gründen nicht übers Netz mit mir agieren.
»»
»» Muß / will ich das verstehen? Wenn sie Policies haben, die verbieten, das Netz zu nutzen, warum lassen sie sich dann auf das viel gefährlichere Spiel ein, Dir über den USB-Stick direkten Zugriff auf den Rechner zu gewähren?
Nö, da sind andere Gründe, die ich jetzt nicht weiter erkläutern werde... Auf jeden Fall brauche ich eine lokale Lösung.

»» Ja, OOO läuft auch ohne JRE, mit minimalen Einschränkungen. (Wobei ich zugeben muß, dass ich den DB-Teil von OOO noch nicht wirklich ohne JRE ausprobiert habe.) Was spricht dagegen, selbst mal zu experimentieren? Ein alter PC oder VMWare, frische OS-Installation, Stick / ISO-Image rein und probieren, ob alles funktioniert.
Habe ich mir auch schon gedacht.

»» »» Kann ich in die Datenbank von Base auch Dateien speichern? Per Datei-Upload-Dialog?
»»
»» Es gibt bei lokalen Anwendungen keinen Upload. Du kannst vielleicht eigenen Programmcode dazu überreden, eine Datei im Binärmodus zu öffnen, den Inhalt zu lesen, und in ein geeignet großes Datenbank-Feld (BLOB) zu schreiben. Oder entsprechend anders herum aus der DB lesen und in eine Datei schreiben.
Ziemlich umständlich...

»» »» In Access kann man glaub ich sogar den Zugriff auf die Entwurfs-Ansicht per Passwort verschlüsseln.
»»
»» Was nicht wirklich was bringt, wenn der Passwort-Schutz trivial zu knacken ist. Die alten MS-Office-Versionen waren da sehr anfällig, wie das bei den neuen aussieht, weiß ich nicht.
Mir geht es nur darum, einen einfachen "Idiotenschutz" ein zu bauen, damit mein Kunde (ältere Menschen inbegriffen) den Datenbestand nicht versehentlich ändert.

»» Ich sehe hier ein großes Problem...
Der geplante Einsatzbereich ist einfach außergewöhnlich. Es sind viele ältere Personen dabei, die z.T. über keinen Web-Anschluss verfügen.

»» Warum brauchst Du überhaupt Dateien UND eine Datenbank? Was genau willst Du bauen?
Ich habe viele Partituren in PDF und anderen Formaten. Diese müssen in einer Datenbank katalogisiert werden, um z.B. die Partitur eines bestimmten Instrumentes von allen Liedern aus zu geben (Drucker etc.).
Ich brauche eine Anwendung, die einfach zu programmieren ist. Der Kunde muss nachher aber die Datenbank einfach abfragen können, Schritt für Schritt selektieren, weil nicht alle sich in Datenstrukturen eindenken wollen. D.h. nicht: "Gib mir alle Partituren mit Instrument soundso und datum soundso" sondern: "Ganzes Lied drucken / lied für Instrument drucken?"-Auswahl usw.
Ich hoffe, ich habe es deutlich machen können.

[Alexander (HH)]

Moin Moin!

Grundprinzip: select aus einer Tabelle, abhängig vom gerade benötigten Code, String-eval, um aus dem String aus der Datenbank Programmcode im Arbeitsspeicher zu machen, Routinen aufrufen. In Perl z.B. mit einem Hook in @INC.
Das Grundprinzip war mir klar...

Tja, der Rest ist abhängig davon, welche Sprache(n) du einsetzen willst. RTFM, wenn das nicht hilft, solltest Du über eine andere, besser dokumentierte Sprache nachdenken.

(Mal so am Rande: In Java müßte so eine Perversion auch funktionieren, mit einem eigenen Class Loader, der sich die binären *.class-Dateien aus der DB fischt, sogar ganz ohne String-Eval. Aber Java ist ja wegen der notwendigen JRE schon aus dem Rennen.)

Aber wozu das? Wenn Du schon Updates verteilst, dann kannst Du auch den Programmcode austauschen statt in der DB herumzueiern.
Da hast du Recht.

Was spricht dagegen, selbst mal zu experimentieren? Ein alter PC oder VMWare, frische OS-Installation, Stick / ISO-Image rein und probieren, ob alles funktioniert.
Habe ich mir auch schon gedacht.

Fang an. Bau Dir einen häßlichen Prototypen mit 1% Funktionsumfang in Deiner Lieblingssprache, meinetwegen auch noch mit einem erforderlichem Runtime Environment. Wenn das KONZEPT funktioniert, schmeiß den ganzen Prototypen-Code weg (weil der in aller Regel total verbastelt ist) und bau es noch mal sauber, in einer Sprache, die zu Deinen Rahmenbedingungen paßt (d.h. u.a. keine Runtime Environment nötig oder mit portablem Runtime Environment).

Wenn Du Dir einen riesigen Gefallen tun willst, setzt VORHER eine Source-Verwaltung auf. Wenn Dir nichts besseres einfällt, nimm Subversion. Commit early, commit often, aber nur funktionierenden Code. Kommentiere die Commits, und vor allem dokumentiere Deinen Code. Kommentare im Code sind keine Dokumentation. Halbautomatisch aus dem Code generierte Doku ist das Minimum (javadoc, POD, ...). Dokumentiere Deine Konzepte und Datenstrukturen. Pack die entsprechende Dokumentation mit in die Source-Verwaltung. (Daraus resultiert: Dokumentiere in diff-baren Datenformaten wie HTML, Docbook, POD.) Pflege die Doku. Denk dran, dass Du die Doku für Dein 10 Jahre älteres Ich (und dessen Kollegen) schreibst, dass die meisten Grausamkeiten der Startphase längst verdrängt hat, und dich für jedes Stück undokumentierten Code und für jedes Stück falsche, veraltete, oder ungenaue Dokumentation abgrundtief hassen wird.

Kann ich in die Datenbank von Base auch Dateien speichern? Per Datei-Upload-Dialog?
»»
Es gibt bei lokalen Anwendungen keinen Upload. Du kannst vielleicht eigenen Programmcode dazu überreden, eine Datei im Binärmodus zu öffnen, den Inhalt zu lesen, und in ein geeignet großes Datenbank-Feld (BLOB) zu schreiben. Oder entsprechend anders herum aus der DB lesen und in eine Datei schreiben.
Ziemlich umständlich...

Umständlicher, als ein paar Megabyte Browser in Gang zu setzen, eine Datei im Binärmodus zu öffnen, den Inhalt zu lesen, in einen HTTP-Request zu verpacken, Hostnamen aufzulösen, TCP-Socket zu öffnen, den Request über den Socket an ein paar weitere Megabyte Webserver zu schicken, der den HTTP-Request teilweise zerlegt, an weitere Megabytes Code übergibt, die den HTTP-Request komplett zerlegen, die Datei extrahieren, und in ein geeignet großes Datenbank-Feld schreiben. Nee, is' klar ... o_O

Wie hättest Du es denn gerne? Einmal mit dem Zauberstab wedeln und die DB macht den Job ganz alleine, ohne dass Du Code schreiben mußt? So einfach ist das leider nicht. (Obwohl manche RDBMS' durchaus Dateien direkt lesen können, nur vielleicht nicht unbedingt so, wie Du es brauchen kannst.)

In Access kann man glaub ich sogar den Zugriff auf die Entwurfs-Ansicht per Passwort verschlüsseln.
»»
Was nicht wirklich was bringt, wenn der Passwort-Schutz trivial zu knacken ist. Die alten MS-Office-Versionen waren da sehr anfällig, wie das bei den neuen aussieht, weiß ich nicht.
Mir geht es nur darum, einen einfachen "Idiotenschutz" ein zu bauen, damit mein Kunde (ältere Menschen inbegriffen) den Datenbestand nicht versehentlich ändert.

Wie wäre es mit einer Read-only-Datenbank? CDB wird nachgesagt, rasend schnell zu sein -- und natürlich Read-Only. Da KANN niemand versehentlich was ändern. Dafür hat CDB ein paar andere Nachteile. So kannst Du mit CDB ohne Extra-Arbeit SQL erst einmal vergessen.

Warum brauchst Du überhaupt Dateien UND eine Datenbank? Was genau willst Du bauen?
Ich habe viele Partituren in PDF und anderen Formaten.

Dir ist bewußt, dass Windows ohne fremden Code nichts mit PDF-Dateien anfangen kann? Du brauchst also auch noch einen Portablen PDF-Viewer, der sich aus deiner Applikation steuern läßt. Oder Du integrierst eine entsprechende Library in Deine Applikation. Das gleiche gilt für nahezu alle anderen Formate, bis auf RTF, Plain Text, Windows Bitmaps, und das alte *.WRI-Format.

Wenn Du die alternativen Betriebssysteme berücksichtigen willst (Du hast immer noch nicht definiert, welche das sein sollen!), brauchst Du die Dateiformat-Viewer auch noch für die anderen Betriebssysteme, und viel mehr als HTML und Plain Text kannst Du nicht als lesbar voraussetzen. Je nach Betriebssystem könnte sogar HTML zu einem Problem werden.

Diese müssen in einer Datenbank katalogisiert werden, um z.B. die Partitur eines bestimmten Instrumentes von allen Liedern aus zu geben (Drucker etc.).

Ich brauche eine Anwendung, die einfach zu programmieren ist. Der Kunde muss nachher aber die Datenbank einfach abfragen können, Schritt für Schritt selektieren, weil nicht alle sich in Datenstrukturen eindenken wollen. D.h. nicht: "Gib mir alle Partituren mit Instrument soundso und datum soundso" sondern: "Ganzes Lied drucken / lied für Instrument drucken?"-Auswahl usw.

Der Kunde programmiert nicht, der Kunde fragt ab. Deine Anforderung lautet also korrekt: "Ich brauche eine Anwendung, die einen einfachen Weg bietet, die gespeicherten Daten abzufragen."

Du brauchst also vermutlich sehr viele gut aufbereitete Metadaten, und eine sehr benutzerfreundliche Abfrageschnittstelle. Klingt nach viel Arbeit, insbesondere wenn Du Deinen Kunden nicht zumuten willst, sich alles selbst per SQL aus der DB zu fummeln.

Aber meine Kunden wollen aus div. Gründen nicht übers Netz mit mir agieren.

Der geplante Einsatzbereich ist einfach außergewöhnlich. Es sind viele ältere Personen dabei, die z.T. über keinen Web-Anschluss verfügen.

Deine Kunden KÖNNEN nicht, weil sie keinen Netzanschluß haben. Das ist etwas anderes als sie WOLLEN nicht.

Wenn sie bereit sind, für Deine Applikation Geld auszugeben, warum sind sie dann nicht bereit, für den Zugang zu Deiner Applikation Geld auszugeben?

Ein Internet-Zugang sollte in Mitteleuropa nahezu überall möglich sein, wenn auch nicht immer mit hoher Bandbreite. Wo ein analoger Telefonanschluß vorhanden ist, funktioniert auch ein Modem. Und wenn ich mich recht erinnere, gab es schon zu Bundespost-Zeiten die Aussage, dass an JEDEM Telefonanschluß in Deutschland ISDN möglich ist.

Zugegeben, 56 kBit/s per analogen Modem oder 64/128 kBit/s per ISDN ist nicht sonderlich schnell, aber für eine einfache Web-Oberfläche ohne viel Schnickschnack reicht das vollkommen aus. Das Ergebnis der Suchanfragen wird so lange eine (datenmäßig kleine) Liste von Dokumentbeschreibungen ("Schillers Glocke, in der Vertonung von Hein Blöd, für Dampfkessel und Kochlöffel, Januar 2010, PDF") sein, bis der jeweilige Kunde gefunden hat, was er sucht. Das geht auch über schmalbandige Internet-Anschlüsse problemlos. Erst dann wird das eigentliche Dokument heruntergeladen, optional mit GZIP-Komprimierung der Nutzdaten, die mittlerweile fast jeder Browser beherrscht. Wahlweise bietest Du auch noch "runtergerechnete" Dokumentversionen an, die automatisch aus den "vollen" Dokumenten berechnet werden (reduzierte Auflösung, reduzierte Farbtiefe, platzsparenderes Dokumentenformat).

Alexander

[Alexander (HH)]

Moin Moin!

Ich brauche also

• Portabilität (d.h. ohne Installation sofort und von USB-Stick)

Installation ist auch unter Windows nicht zwangsweise nötig, man kann (einige) Applikationen auch einfach auf irgendein Laufwerk kopieren und von dort starten.

"Richtige" Datenbanken (Oracle, PostgreSQL, SQL Server) müssen aber so tief ins System eingebunden werden, dass Du dort sehr wahrscheinlich nicht ohne Installation auskommen wirst.

SQLite kann in eine Applikation gelinkt werden und verwaltet dann völlig einenständig und ohne Installation eine relationale Datenbank mit SQL-Interface, die als Storage nur ein Verzeichnis auf irgendeinem Laufwerk braucht.

• Daten werden nur auf USB-Stick angelegt

s.o. SQLite würde passen.

• Unterstützung von alternativen BS wäre auch nicht verkehrt

Welche?

BeOS? Xenix? Solaris? Irgendwelche BSDs? FreeDOS?

Da wirst Du mit einer Windows-EXE nicht weit kommen. Nimm irgendeine gängige Scriptsprache oder eine auf einer VM aufsetzende compilierte Sprache wie z.B. Java, für die auf den "alternativen BS" standardmäßig ein Runtime Environment vorhanden ist, und pack ein entsprechendes Runtime Environment für Windows auf den Stick. Nach Deinen Anforderungen muß dieses ohne Installation auskommen, also scheidet Java (meines Wissens) schon mal aus.

Perl ist auf gängigen Unixen vorhanden, allerdings nicht immer in der neuesten Version. Für Windows gibt es z.B. Strawberry Perl Portable, dass ohne Installation auskommt.

SQLite gibt es für Perl (DBD::SQLite), allerdings mußt Du es in aller Regel selbst compilieren. Das kann ggf. "on demand" auf dem Stick erfolgen, wenigstens Strawberry Perl bringt freundlicherweise gleich einen kompletten C-Compiler samt make & Co mit. Auf "alternativen BS" sieht es mit dem C-Compiler allerdings gelegentlich etwas finster aus.

Wenn ich die Datenbank dann auch noch (nach Eingabe des Passworts) portabel auf dem Stick bearbeiten kann, umso besser.

Was für ein Passwort? Schon wieder eine neue Anforderung?

Wie willst Du den Passwort-Schutz haben: Nur sicher gegen Amateure? Dann pack einfach eine Tabelle mit Namen und ge-hash-tem und ge-salt-etem Passwort in die DB und prüfe beim Login, ob für den eingegebenen Namen ein Datensatz existiert, für den der "salted hash" des EINGEGEBENEN Passworts mit dem Wert in der DB übereinstimmt.

Wenn Du mehr brauchst, wirst Du die DB hart verschlüsseln müssen - nicht unproblematisch, denn zum Arbeiten braucht die Anwendung einen Schlüssel um Entschlüsseln, und den Entschlüsselungsalgorithmus. Ein versierter Angreifer kann damit alle Daten zurückgewinnen. Du mußt also dafür sorgen, dass der Schlüssel erst dann verfügbar ist, wenn ein passendes Passwort eingegeben wurde. Z.B. indem Du den Schlüssel mit dem Passwort hart verschlüsselst.

Noch besser wäre, wenn ich auch die Dialogführung von meiner Datenbank abhängig machen kann. Dann könnte ich nämlich ein Software-Update per Aktualisierung der Datenbank durchführen.

Mit einer Scriptsprache ist es kein großes Problem, große Teile des Programmcodes in der Datenbank zu halten. Ob das clever oder sinnvoll ist, ist eine andere Frage.

Warum tauschst Du für Updates nicht einfach die alten USB-Sticks gegen neue, die ein Script auf deinem Master-Server vollautomatisch löscht und mit dem neuesten Stand bespielt?

Wenn Du einen Internet-Zugang (minimal HTTP) voraussetzt,  kannst Du Dir das ganze Theater sparen und die Daten stumpf über HTTP abfragen und ausliefern, Du mußt nicht alle Daten in die Hände Deiner Kunden geben, usw. usw. Und HTTP/HTTPS funktioniert ab Win98 relativ schmerzfrei (wenn auch wegen des antiken IEs nicht immer hübsch), auch auf so ziemlich jedem anderen Betriebssystem, dass einen Browser mitbringt.

Alexander