nicht angemeldet
CVS-DB
Hallo,
ich habe eine Access-DB mit ca. 500 Datensätzen, die einmal pro Monat aktualisiert und als .CVS ins Netzt gestellt werden soll. Um nicht alle HTML-Seiten ständig akutalisieren zu müssen dachte ich an ein CGI- bzw. Perl-Script.
Das Script sollte folgende Aufgaben erfüllen:
- Nutzung eines HTML-Templates welches durch Aufruf des Scripts "aufgefüllt" wird
- Ansteuerung einzelner Rubriken durch Hyperlink und entsprechender Ausgabe des Inhalts
- Suchmöglichkeit über alle Rubriken hinweg (Ausgabe-Layout gemäß HTML-Template)
Von der Arbeitsweise her ähnlich wie der Aufbau von "Yahoo" nur dass es sich um keine Linkliste sondern um eine Preisliste handelt.
Auf meiner Suche im www habe ich zwar ähnliche DB-Scripts gefunden, jedoch keines, dass meine Anforderungen erfüllt.
Meine Fragen an euch:
1. Kennt jemand ein hierfür geeigenetes Script?
2. Hat eventuell jemand Interesse daran eins zu erstellen? Natürlich nicht umsonst.
3. Liese sich das auch mit PHP realisieren?
Schon mal vielen Dank & Gruß,
Alex
-
ich habe eine Access-DB mit ca. 500 Datensätzen, die einmal pro Monat aktualisiert und als .CVS ins Netzt gestellt werden soll. Um nicht alle HTML-Seiten ständig akutalisieren zu müssen dachte ich an ein CGI- bzw. Perl-Script.
Ich denke, Du vermischst schon hierbei zwei mögliche Lösungsstrategien:
a) CGI: Erlaubt Dir den online-Zugriff auf Deine Daten, also ständige Aktualisierung, nicht nur monatliche. Verlangt dafür aber ständige Verfügbarkeit der Datenbank und erzeugt unvorhersehbare Last auf dem Server.
b) Batch-Generierung der Seiten: Das erfüllt eher Dein Modell mit der monatlichen Aktualisierung. Du erstellst ein Programm, das alle verfügbaren Seiten nacheinander generiert und als HTML-Dokumente ablegt. Die interne Schnittstelle zur Datenbank ist identisch zu a), nur die Aufrufkonventionen nach außen sind anders (kein CGI), und das Programm muß alle Seiten erzeugen, während a) jeweils nur eine Seite erzeigt. Der Generierungsvorgang sollte automatisiert werden (wie immer das auf Windows gehen mag).
-
a) CGI: Erlaubt Dir den online-Zugriff auf Deine Daten, also ständige Aktualisierung, nicht nur monatliche. Verlangt dafür aber ständige Verfügbarkeit der Datenbank und erzeugt unvorhersehbare Last auf dem Server.
Hallo Michael,
danke für deine Antwort.
Eine elegantere Lösung wäre mit Sicherheit mySQL/PHP. Doch die Leute, für die ich diese Seite erstelle, sind nicht so firm in diesen Dingen. Eine Aktualisierung wäre so recht einfach durchzuführen: Die Access-DB befindet sich auf einem Arbeitsplatzrechner, wird aktualisiert, als .CVS exportiert und auf dem Webserver abgelegt. Alles weitere erledigt das Script.
Die Belastung des Servers düfte aufgrund nicht allzu häufiger Zugriffe recht gering bleiben.Mag sein, dass ich die Einsatzmöglichkeiten eines solchen Scripts falsch einschätze. Müsste jedoch funktionieren, oder?
Gruß,
Alex
-
Eine elegantere Lösung wäre mit Sicherheit mySQL/PHP. Doch die Leute, für die ich diese Seite erstelle, sind nicht so firm in diesen Dingen.
Ich habe aus meiner Beschreibung ganz bewußt jegliche Erwähnung einer Programmiersprache herausgelassen. Dafür ist es zu diesem Zeitpunkt viel zu früh.
Lege Dich erst einmal auf ein Betriebskonzept fest - die passenden Tools wirst Du dann schon finden.Eine Aktualisierung wäre so recht einfach durchzuführen: Die Access-DB befindet sich auf einem Arbeitsplatzrechner, wird aktualisiert, als .CVS exportiert und auf dem Webserver abgelegt.
Alles weitere erledigt das Script.
Das scheint meinem Modell b) zu entsprechen.
Übrigens: Meinst Du mit "CVS" eventuell "CSV"?Die Belastung des Servers düfte aufgrund nicht allzu häufiger Zugriffe recht gering bleiben.
Mag sein, dass ich die Einsatzmöglichkeiten eines solchen Scripts falsch einschätze. Müsste jedoch funktionieren, oder?Genau dies hängt davon ab, für welches Betriebskonzept Du Dich entscheidest ...
-
Hallo Michael,
Ich habe aus meiner Beschreibung ganz bewußt jegliche Erwähnung einer Programmiersprache herausgelassen. Dafür ist es zu diesem Zeitpunkt viel zu früh.
Lege Dich erst einmal auf ein Betriebskonzept fest - die passenden Tools wirst Du dann schon finden.Ich denke das Betriebskozept wird Variante B sein. Es ist meiner Meinung nach die einfachste Möglichkeit für Nicht-Programmierer den Datenbestand ohne größeren technischen Aufwand aktuell zu halten.
Das scheint meinem Modell b) zu entsprechen.
Übrigens: Meinst Du mit "CVS" eventuell "CSV"?Oh, peinlich, da liegt der Fehler im Detail. Natürlich meine ich CSV. Hoffentlich nur ein Tippfehler... <g>
Genau dies hängt davon ab, für welches Betriebskonzept Du Dich entscheidest ...
Ich werde Konzept B realisieren. Wegen der Serverbelastung: Ich schätze, dass max. 10 User/Tag zugreifen werden - wenn überhaupt.
Ich würde mich freuen, wenn Du eventuell noch ein paar Tips bezüglich Konzept B hättest.
Vielen Dank und Gruß,
Alex
-
Ich denke das Betriebskozept wird Variante B sein. Es ist meiner Meinung nach die einfachste Möglichkeit für Nicht-Programmierer den Datenbestand ohne größeren technischen Aufwand aktuell zu halten.
Ob die Daten online oder in größeren zeitlichen Abständen gelesen werden, hat nichts damit zu tun, wer sie womit schreibt.
Das scheint meinem Modell b) zu entsprechen.
Übrigens: Meinst Du mit "CVS" eventuell "CSV"?
Oh, peinlich, da liegt der Fehler im Detail. Natürlich meine ich CSV. Hoffentlich nur ein Tippfehler... <g>Okay, comma separated variable fromat läßt sich mit praktisch allen Programmiersprachen leicht verarbeiten. Eine split()-Funktion wie in Perl wäre trotzdem hilfreich, aber die kann man sich auch leicht selbst schreiben.
Ich werde Konzept B realisieren. Wegen der Serverbelastung: Ich schätze, dass max. 10 User/Tag zugreifen werden - wenn überhaupt.
Bei so wenig Last würde nichts gegen Modell A sprechen - dessen "Schwachpunkt" ist eher die hohe erforderliche Verfügbarkeit der Datenbank.
Ich würde mich freuen, wenn Du eventuell noch ein paar Tips bezüglich Konzept B hättest.
Außer meinen Angaben in einem vorherigen Posting: Wenn Du keine Standard-Web-Schnittstelle (wie CGI) bedienen mußt, dann bist Du etwas freier in der Wahl Deiner Programmiersprache. Diese würde ich so optimieren, daß ich die Daten möglichst gut ansprechen kann.
In Deinem Falle könnte das bedeuten, daß Du den Export ins CSV möglicherweise bleiben läßt und direkt per SQL auf die Datenbank zugreifst. Vielleicht ist das aufwenidiger zu programmieren, aber dafür ist es ein Zwischenschritt weniger, was die Komplexität des Gesamtsystems in Grenzen hält.
Solltest Du bei CSV bleiben, dann würde ich als reinen Datei-Filter (CSV einlesen, HTML ausgeben) Perl vorschlagen (kompakte, mächtige Routinen und plattformunabhängig, zudem ist Performance in Modell B und bei Deinen überschaubaren Datenmengen sekundär).
-
Solltest Du bei CSV bleiben, dann würde ich als reinen Datei-Filter (CSV einlesen, HTML ausgeben) Perl vorschlagen (kompakte, mächtige Routinen und plattformunabhängig, zudem ist Performance in Modell B und bei Deinen überschaubaren Datenmengen sekundär).
Hallo Michael,
nochmals vielen Dank für deine Hilfestellung und Anregungen.
Ich werde Konzept B - csv in Verbindung mit Perl realisieren. Ich denke es ist die einfachste Methode.
Also, nochmals danke und Gruss,
Alex
-
-
-
-
-
-
Hallo,
Mein Tipp wäre das Programm Links 2 von http://www.gossamer-threads.com/.
Damit ist einiges von Deinen Wünschen machbar.
Hoffe ein bißchen geholfen zu haben.
Gruß HaPe