Log von Änderungen etc.

[Threin]

Hey,

ich will für mein DB-System ein kleines Log-System basteln und das in Verbindung mit C# aber ich hätte ein paar Fragen zu dem Aufbau, ob das so möglich ist.
DAs hier ist die Tabelle in der Datenbank

CREATE TABLE IF NOT EXISTS Log(
LogID int(11) NOT NULL AUTO_INCREMENT,
Reason varchar(10) NOT NULL,
UserID int(11) NOT NULL,
CustomerID int(11) NOT NULL,
Datetime date NOT NULL,
PRIMARY KEY (LogID),
foreign key(UserID) references User(UserID),
foreign key(CustomerID) references Customer(CustomerID)
ENGINE=InnoDB;

Ich will jetzt bei Reason z.B sowas wie updates, deleted usw. stehen haben, dann sollte der Typ ja wohl varchar sein oder, das kann man dann ja da dann als Text immer rein schreiben oder gibt es da eine bessere Möglichkeit?
Dann soll sich nocht gemerkt werden, welcher Kunde bearbeitet wurde und von welchem Benutzer / Admin oder was auch immer der Kunde bearbeitet wurde und natürlich das Datum oder würde da auch als Datentyp der Timestamp gehen? Das soll ja das aktuell Datum sein, am besten warscheinlich mit Stunde, Minute & Sekunde?

Dann müsste man dann ja nachher, wenn mit einem Kunden irgendetwas passiert auch die BenutzerID holen, das sollte dann ja wohl in Ordnung sein, wenn man den Namen in einer Variable speichert und dasselbe ja auch mit dem Kunden?
Sollte man denn evtl. auch noch eine Art 2. Tabelle vom Kunden erstellen, also wo der "alte" bzw. Datensatz des Benutzers, falls er nicht gelöscht wurde noch gespeichert ist?

[Ralf Jansen]

Ich will jetzt bei Reason z.B sowas wie updates, deleted usw. stehen haben, dann sollte der Typ ja wohl varchar sein oder, das kann man dann ja da dann als Text immer rein schreiben oder gibt es da eine bessere Möglichkeit?

Da es nur eine begrenzte Möglichkeit von reason(s) gibt ist freitext irgendwie übertrieben und schwerer auswertbar als die möglichen Gründe einfach durchzunummerieren.

Dann soll sich nocht gemerkt werden, welcher Kunde bearbeitet wurde und von welchem Benutzer / Admin oder was auch immer der Kunde bearbeitet wurde und natürlich das Datum oder würde da auch als Datentyp der Timestamp gehen? Das soll ja das aktuell Datum sein, am besten warscheinlich mit Stunde, Minute & Sekunde?

Deine Datenbank sollte irgendeine Funktion haben das aktuelle Datum zu bestimmen. Die Funktion kannst du ja als DefaultWert für deine date Spalte nehmen. Denn in einer Log Tabelle wird wohl nie geupdatet( das würde dann ja unter Manipulation laufen).

Dann müsste man dann ja nachher, wenn mit einem Kunden irgendetwas passiert auch die BenutzerID holen, das sollte dann ja wohl in Ordnung sein, wenn man den Namen in einer Variable speichert und dasselbe ja auch mit dem Kunden?

Wenn du den Systembenutzer meinst ist das systemabhängig ob es da nur einen string gibt oder eine ID oder was auch immer was den aktuell angemeldeten User identifiziert. Wir wissen ja nicht mal ob bei dir einen Datenbankuser gibt, nur einen Windowsuser (Single-Sign-on) oder nur logische User vor der Datenbank aber nicht mehr unterscheidbar in der Datenbank.

Sollte man denn evtl. auch noch eine Art 2. Tabelle vom Kunden erstellen, also wo der "alte" bzw. Datensatz des Benutzers, falls er nicht gelöscht wurde noch gespeichert ist?

Log ist nur ein Wort. Was du genau willst wissen wir nicht. Daher haben wir auch keine Ahnung ob diese Tabelle dann dafür nötig wäre.

[Threin]

Wegen solchen Sachen habe ich ja auch gefragt, durchnummerieren wäre auch ne Möglichkeit oder man macht für die Reasons noch eine eigene Tabelle, also sowas:

CREATE TABLE IF NOT EXISTS Reason(
ReasonID int(11) NOT NULL AUTO_INCREMENT,
Reason varchar(10) NOT NULL,
PRIMARY KEY (LogID)
ENGINE=InnoDB;

dann die ReasonID als Foreign key in der Tabelle Log oder ist das auch zu überzogen?
Es gibt ja auch eigentlich, zumindest meiner Ansicht nach ja nur 4 Sachen, die gemacht werden können:
Ein Kunde kann hinzugefügt werden, er kann bearbeitet werden, er kann gelöscht werden und es kann nach ihm gesucht werden.

Die Funktion der Datenbank für die Zeit ist ja bei MySQL "Timestamp" oder sowas, jedenfalls soweit ich weiß.

Ich habe für die Benutzer extra eine Tabelle gemacht, wo dann die Benuzer eingetragen sind aber es gibt ja auch noch den "Datenbank-Benutze" selbst, also z.B root, wie würde man den denn in die Tabelle log mit reinkriegen oder gibt es da auch eine Funktion für? Nur so aus Interesse.

Mmm .. stimmt schon, das hätte ich velleicht noch ein wenig ausschreiben sollen.
Ich interessiere mich sehr für die Sachen, die auch nachher bei größeren Projekten etc. Anwendung finden und ob es sinvoll wäre, das man vielleich auch eine Tabelle hat, die den Benutzer "vor" der Änderung hat, falls er den geändert wurde, bzw. gelöscht? Warscheinlich ist es schon sinnvoll sowas zu machen oder? Schließlich kann man ja nativ von MySQL aus keine einzelnen Datensätze wiederherstellen, zumindest soweit ich weiß.
Es gibt ja wohl noch das Rollback aber soweit ich weiß, würde sich das ja dann auf alle Datensätze und auch Tabellen auswirken?

Ich arbeite derzeit an einem Kundenverwaltungssystem aber dies nur für mich, also nicht kommerziell.

[Christian Marquardt]

CRUD
Create
Read
Update
Delete

Suche ist im allgemeinen keine DB verändernde Operation

[Ralf Jansen]

Warscheinlich ist es schon sinnvoll sowas zu machen oder? Schließlich kann man ja nativ von MySQL aus keine einzelnen Datensätze wiederherstellen, zumindest soweit ich weiß.

Wenn du mal scharf nachdenkst ist eine solche automatische Funktion auch nur in einer Fabelwelt denkbar bzw. nur auf die allersimpelsten relationalen Modelle anwendbar was sich dann ja mit deiner Frage nach 'die auch nachher bei größeren Projekten etc. Anwendung finden' beißt. Wenn eine Historisierung/Versionierung von Daten nötig ist wird das logisch vor der Datenbank stattfinden und dann einen ganzen Objektgraphen umfassen und nicht ein einzelnes Objekt (Datensatz einer Tabelle). Und diese Datenstruktur sollte dann in der Datenbank auch keinerlei Abhängigkeiten außerhalb seiner eigenen Struktur haben (aka es muß ein sich geschlossenen Dokument, oder wie man das dann auch immer nennen möchte, sein).

[defo]

Falls Du noch mal reinschaust, ein paar Gedanken zu Deinem Anliegen.
Wie willst Du loggen?
Alle Serversysteme (DB, Webserver, ..) loggen sowieso, und zwar in Dateien. Teilweise gibt es auch bei DB Servern API dazu, die über Trigger, Stored Procedures angesprochen werden können. Das charmante beim Log in eine Datei ist die Unabhängigkeit vom DB Server Zustand. Ein Deadlock oder so kann man noch weiterhin loggen. Natürlich ist der Zugriff nicht so bequem wie bei einer Tabelle, das muss man abwägen oder mglw 2gleisig fahren. Der Ressourcenbedarf dürfte auch relativ klein sein verglichen mit Table Log.
Was willst Du loggen?
Delete ist wie Ralf Jansen schon schrieb eine Frage des Modells. Sobald Du mit Ref. Constraints arbeitest- was Du tun solltest-, führt ein Delete entweder zu einem Fehler oder es löscht kaskadiert eine ganze Reihe von Datensätzen. Das kann man im Prinzip loggen, aber der Umgang damit hat nichts mit dem Log zu tun. Dazu kommt, dass es idR. bei Marktlösungen Vorschriften zu Aufbewahrungszeiten gibt, gerade bei Systemen die per Definition mit Kundendaten zu tun haben. Einfach löschen ist nicht der richtige Weg. Historisierungsverfahren solltest Du Dir mal unabhängig vom Logging anschauen und einbauen.
Fehler will man eigentlich auch loggen, ebenso wie Warnungen, vielleicht auch Debug Informationen. Den größten Nutzen hat man da, wenn ein "Application Log" alles an einem Platz in der zeitlichen Reihenfolge reinkommt.
Benutzer ist toll, aber vielleicht zu wenig. Hilfreich wären Maschinenname, IP, (DB)Session, so können auch Mehrfachlogins eines Users unterschieden werden und im Fehlerfall sinnvoll separiert werden.
Zuletzt will man möglichst wenig loggen, in der Breite, wie in der Tiefe. Also wo es geht, ID statt Text, Änderung der Logtiefe je nach Bedarf, nur Fehler, auch Warnungen, usw.. . Und wie schon angedeutet, das Log sollte keinen Funktionen für die Anwendung bereitstellen nur loggen.