nicht angemeldet
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).