Einzelnen Beitrag anzeigen

Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
3.159 Beiträge
 
#15

AW: Export der Kassendaten für Statistiken

  Alt 13. Apr 2012, 10:11
Views möchte ich ungern anbieten. Erstmal muss der Kunde spezielle Datenbanktreiber haben und zweites müssen wir da noch aufpassen dass der Kunde nicht die DB crasht durch polling etc..
Außerdem wird er über Änderungen nicht so informiert falls es neue Kassendaten gibt.
Hatte ich mich falsch ausgedrückt? Die DB crasht doch nicht. Es geht evtl. nur die Performance des DBMS runter. Und sowas auf einem Produktiv-System wäre einfach nicht wünschenswert. Der sichere und störungsfreie Betrieb muss ja gewährleistet werden. Aber das passiert halt auch nur unter gewissen Umständen und hier ist einfach Vorsicht geboten, denn der Kunde schimpft dann auf deine Software und nicht unbedingt auf das evtl. dumm programmierte Auswertsystem.

Das Problem mit dem Treiber ist doch eigentlich kein Problem, da man doch eigentlich keine speziellen Treiber verwendet, oder? Man verwendet nur eine entsprechende Version, die doch überall installierbar ist. und das in einer Doku zu erwähnen ist doch kein Problem. Oder passt ihr Treiber für den DB-Zugriff an, dass kein anderer das nutzen kann? Hm...

Ich stelle mir mehrere Exports vor.
1. Export der Kassendaten in Kopfdaten, Detaildaten und eine gemeinsame Datei direkt nach dem Kassiervorgang.
2. Export der Tagesabrechnung die dann die Umsätze zusammen enthält.
Warum so kompliziert? Alles in eine Datei rein klatschen, eine Doku dazu schreiben, wie diese Datei aufgebaut ist und dem Kunden so ausliefern. Man muss es sich extra für den Kunden doch nicht schwerer machen, als es sein muss. Zudem weiß man eh nicht genau, was der Kunde später dann aus den Daten machen will, d.h. einfach eine Maximaldatei liefern und alles ist erledigt. Selbst anpassbar würde ich diese Export nicht machen, da die Daten später ja immer noch vom Kunden gefiltert werden können -- lieber zu viel, als zu wenig liefern.

Alles als CSV Datei mit dem Datum als Dateinamen damit die einzelne Datei nicht zu voll wird. Plattenplatz spielt eine untergeordnete Rolle.
Der Kunde kann dann diese Datei parsen und in eine eigene DB schreiben oder direkt in Excel etc. verarbeiten.
Das Verhalten kannst du ja mit dem Kunden abklären. Wobei ich da nicht zu viel Aufwand rein stecken würde. Will er nur die letzten x Tage in einem Verzeichnis stehen haben, so kann er sich ja einen CronJob basteln. Deine Anwendung liefert halt Tag für Tag alle Daten in ein Verzeichnis. Alles andere ist imho nice-to-have.
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)
  Mit Zitat antworten Zitat