Einfache Datenbank mit HTML/Javascript möglich?

[Rolf B]

Hallo Felix,

Aber über ein Formular in einem HTML-Dokument Daten zu erfassen und dauerhaft abzuspeichern...

ist nicht der geschilderte Usecase. Ich lese, dass die HTML Dateien im Quellcode editiert werden und durch Informationen aus einem Repository (die Datei A) „angereichert“ werden sollen.

Das ist auch ein einigermaßen dickes Brett.

Ja, man kann eine Serverlösung erstellen, die das Repository in einer Datenbank abbildet, eine Pflegeoberfläche dafür anbietet und serverseitig die Informationen in die HTML Dateien einträgt (die dann mutmaßlich PHP Dateien werden). Aber:

• Das setzt deutlich mehr Skill voraus, als Yavis für sich reklamiert
• Eine selbstgeschriebene 100%-custom Lösung dürfte zu teuer in Erstellung und Wartung sein

Deshalb sollte man versuchen, eine Bohrung in diesem Brett zu vermeiden. Entweder legt man die Leitung drumherum, oder man schaut sich um, welche fertig gebohrten Bretter zu haben sind.

Eins davon könnte eine Lösung mit MS Access (oder kompatiblen Produkten) sein. Access-Datenbanken kann man als Datenquelle in Excel einbinden. Und man kann Access als Application verwenden, die Formulare anzeigt und aus Datenbanken befüllt. Damit nähert man sich aber wieder der Custom-Lösung.

Es gibt bestimmt auch fertige CRM^[1]-Standardsoftware, die Yavis' Usecases annähernd abdeckt. Bzw. Supplier Management oder Provider Management, je nach Sichtweise. Dazu müsste man die Usecases exakt analysieren und ggf. an die Möglichkeiten von Standardsoftware anpassen. Das können wir hier nicht leisten, dafür bräuchte er einen IT-Beraterdienst mit Marktkenntnis, bei dem aber der Einwurf etlicher kleiner Münzen erforderlich wäre, damit dort auch nur ein Bleistift angefasst wird. Mir scheint aber, die dafür erforderlichen Münzsäcke sind nicht vorhanden oder sollen anderswo eingeworfen werden. Abgesehen davon muss eine solche Software auch gekauft /lizenziert und betrieben werden.

Wenn man all das vermeiden und das Brett lieber umgehen will, dann ist der Ansatz von Yavis als einfache Behelfslösung denkbar. Man würde die Office-Dokumente durch HTML Dateien ersetzen und diese binden das zentrale Repository (die Datei A) ein, um dessen Informationen in die Platzhalter der Seite einzusetzen. Die HTML Dateien würden von Hand editiert. Nicht schick, aber denkbar. Und sie würden sich damit immerhin schonmal verbessern. Statt von file:/// zu lesen könnte man auch einen einfachen, nur lokal zugänglichen Webserver verwenden (Windows bringt einen IIS mit) und die Dateien per http://^[2] laden. Die Daten ließen sich dann auch per fetch() holen.

Probleme Herausforderungen sehe ich hier:

• Was ist, wenn mehrere Leute das Repository oder eine HTML Datei gleichzeitig ändern - das muss man organisatorisch lösen. Office enthält einen Schutz gegen parallele Bearbeitung, ein Texteditor erstmal nicht.
• Was ist, wenn es Datenschutzbedenken gibt (Personengruppe 1 darf einen Teil der Einträge im Repository nicht sehen)? - ggf. muss man das Repository in mehrere Dateien teilen (daten-1, daten-2, script)

Rolf

---

1. Customer Relationship Management ↩︎

2. Ja, http. Ein https-Betrieb erfordert Zertifikatspflege. Das muss man auch erstmal können. Für eine interne Lösung, die keine Authentication enthält, reicht http. ↩︎