AW: Export der Kassendaten für Statistiken
Wer mehr Statistik benötigt (als Kunde) als die Software beinhaltet und der Softwarehersteller implementieren möchte, sollte sich darauf einstellen eine separate DB für dieses Vorhaben zu bemühen.
Eine MegaMonsterAuswertung auf ein Produktiv-System loszulassen kommt dem digitalen Selbstmord gleich. Nicht umsonst gibt es Software a la QlikView die genau zu diesem Zweck geschaffen wurde. Und für diese Art von Software würde ich Schnittstellen anbieten. |
AW: Export der Kassendaten für Statistiken
Nun ja. Es wird doch möglich sein, für die Datenbank einen Treiber auf dem System des Kunden zu installieren. Was daran so schlimm sein soll, erschließt sich mir nicht.
Und dann zeigt man ihm, wie man über EXCEL an die Daten rankommt. Fertig. Geld verdient ihr damit, das ihr dem Kunden die Views zur Verfügung stellt, die seinen Vorstellungen entsprechen. Bei einer Kassensoftware sollte es aber reichen, z.B. die Tagesergebnisse als CSV-Datei zur Verfügung zu stellen. So viele Daten sind das ja nicht, weder an Zeilen noch an Spalten. Wir erzeugen z.B. Logdateien im CSV-Format. Der Dateiname ist dabei das Tagesdatum. Der Kunde kann jederzeit auf die letzten N (default = 30) Tage zugreifen. Wenn er sie längerfristig speichern will, bitte sehr. Nichts spricht dagegen, das er sich eine Access-oder-wie-auch-immer-DB bastelt und die Daten dort einbläst. Benötigt er Unterstützung? Klar, machen wir. |
AW: Export der Kassendaten für Statistiken
Wobei ich hier Sir Rufo schon Recht geben muss. Bietet man Views an, so werden alle Queries auf dem Produktiv-System ausgeführt. Jetzt lasst mal so einen Pfuscher auf dem System arbeiten, der non-stop die DB pollt und es halt einfach nicht besser weiß. Wollt ihr wirklich Support für die Fehler anderer spielen? Klar, wenn dafür extra Geld rausspringt wäre das noch unter Umständen okay, aber von dieser Fehlerquelle würde ich definitiv Abstand nehmen und die Daten einfach regelmäßig exportieren. Als Hersteller der Software muss man doch sicherstellen, dass die Funktionalität der Software nicht durch Spielereien gefährdet wird. Ob das genannte Beispiel übertrieben ist, darf jeder für sich entscheiden, nur habe ich echt schon viel zu viel gesehen, als dass ich das für gut heißen würde.
Fazit: das einfachste ist es alles regelmäßg in eine CSV zu klopfen. Ansonsten kann man sich überlegen, ob man nicht noch eine SQLite-DB füttert. Aber diese externe Auswertung hat im eigentlichen System nicht viel zu suchen, wenn ein fremder User darauf zugreifen soll. Jedenfalls wäre ich auch sehr vorsichtig damit. Und zu dieser Treibergeschichte: bietet man eine ordentliche Schnittstelle à la CSV, Access-DB, SQLite, MySQL an, so wird es wohl für den Kunden kein Problem sein einen entsprechenden Treiber oder dergleichen zu installieren. Das sollte dann definitiv nicht das Problem des Herstellers sein. |
AW: Export der Kassendaten für Statistiken
Guten Morgen zusammen,
Danke für eure echt guten Antworten. Also ich fasse mal zusammen und ergänze meine persönliche Meinung dazu. 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. 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. 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. Ich denke damit ist das Thema ausreichend erörtert, oder? Viele Grüße, Jürgen |
AW: Export der Kassendaten für Statistiken
Zitat:
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... Zitat:
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:59 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz