Portable Datenbank

[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