Hi alzaimar,
schön noch mal vor den Feiertagen von Dir zu lesen
Zitat von
alzaimar:
Die Idee mit der Datenbank ist schon mal in Ordnung, irgendwie leichter Overkill, aber es funktioniert. Über Datenmengen würde ich mir keine Gedanken machen. Dann kommen eben ein paar GB zusammen. WTF.
Lol. Prinzipiell absolut richtig.
Zitat von
alzaimar:
Viel wichtiger sind komfortable Auswerte- und Filtermöglichkeiten für den Endanwender. Alte Daten kannst Du immern noch per periodischem Aufräum-Job vernichten/verdichten.
Ich würde mir eher ein paar Gedanken über die Tabellenstruktur machen. Denn was bringt ein Logging, wenn man mit den Informationen nichts anstellen kann. Windows hat da mit den Application-Logs ein paar nette Ansatze, um Speicherplatz zu sparen. Eigne Dir mal ein paar Basis DWH-Techniken an, dann hast Du eine schön schnelle
DB.
Richtig, wobei die Techniken nicht das Problem sind
Ich bin skeptisch aus einem anderen Grund: Bei diesem Projekt gibt es eigentlich nur Geht/Geht nicht. Die Einträge sind dann u.U. durchgeschleifte Fehlermeldungen (1. Stufe Business Logic, 2. Stufe Low-Level soweit notwendig).
Das richtige Debug-Logging findet eine Ebene tiefer statt, also geht es hier nur um das schöne optische: Ja, es geht oder Nein, bei XYZ gab es einen Fehler (und zwar...).
Das Auswerten im Fehlerfall ist per Debug-Logfile viel einfacher, hier ist alles sprachlich genormt, in UTF8 mit ISO 8601 Zeiten etc.pp. Da nimmt der Support einfach einen Logfile-Reader und kann auch ohne
DB schnell nach bestimmten Fehlern suchen.
Etwas mehr Hintergrund zum Verständnis:
Service und
GUI sind entwickelt Bestellungen aus dem Internet abzuholen und das eigentliche Order-Processing durchzuführen (XSLT, Drucken etc). Wenn der Service läuft, schaltet die
GUI die Abholung ab und überlässt das dem Service. Bisher zeigte die
GUI im Fehlerfall noch einen schönen Status, steuerbar per Einstellungen, im Tray / per Audio usw. Ist hier ein Fehler aufgetreten besteht die Möglichkeit über ein Laufzeit-Protokoll nachzusehen, wann wo was schiefging (oder lief).
Ich weiß, daß die Zielgruppe der Anwendung keine manuell gefilterten Abfragen auf die Log-
DB braucht. Dies wäre also oversized und unnötig. Im Bedarfsfall kann man die Datensätze nach Kategorie anzeigen (nur Fehler, nur Info etc). Das reicht schon vollkommen.
Die Anwendung muß nicht viel machen (neben der Datenumwandlung), sondern wir reden hier innerhalb der Haupt-
DB von ~ 100.000 DS p.a. - das ist für eine
DB lächerlich wenig. Da wäre die Log-
DB um den Faktor 1000 größer
Deswegen tat es bisher auch eine In-Memory Tabelle, die eine feste Rotationsgröße hatte (z.B. 100.000 DS). Wegen so kleiner Infos war also eine
DB unnötig und es wurde eine TObjectList genutzt.
Diese soll nun nicht nur
GUI Events, sondern auch zurückliegende Service-Events anzeigen.
Für die eigentliche Fehlersuche gibt es, wie gesagt, eine umfangreiche Log-Möglichkeit mit vielen Abstufungen, Details etc.pp.
Gruß Assertor
Roter Kasten: Das klingt Interessant, Michael. Bevor ich (wieder mal) das
Rad neu erfinde: Kennst Du hier einen Ansatz der nicht zu viel Overhead hat und in Delphi umgesetzt ist. Gibt es auch Lösungen in diesem Bereich ohne externe Abhängigkeiten (MOM im Service?).