schnelles inkrement für logging funktion
RobRobson
- datenbank
Hallo,
ich möchte die Zugriffe auf verschiedene Funktionen messen, sprich beim ausführen bestimmter Funktionen den counter in der logging-tabelle inkrementieren.
Die log_tab schaut so aus:
id|lastupdate|datei|funktion|count
problem ist jetzt das man nicht einfach via INSERT INTO .. ON DUPLICATE KEY UPDATE count =+ 1
setzen kann, da "datei" und "funktion" als text-felder definiert sind und somit nicht als index deklariert werden können.
Der einfachste weg wäre wohl: Ermitteln der id -> dann increment der ID, aber das sind erstens 2 Transaktionen (im Fall eines INSERTS sogar 3) die über php gestartet werden müssten und zweitens würden/könnten race_conditions auftreten.
Gibts also bessere Lösungen oder muss man Lösung 2 nehmen aber sie in globale Transaktion kapseln um die RC zu verhindern?
Wie handeln große Projekte Logs?
Viele Grüße,
Rob
Moin Moin!
Du suchst eine Sequenz, siehe Handbuch / Suchmaschine.
Alexander
Hi und Danke,
Moin Moin!
Du suchst eine Sequenz, siehe Handbuch / Suchmaschine.
http://planet.mysql.com/entry/?id=16008 :
Anders als andere DBMSe kennt MySQL keine SEQUENCE Objekte. Statt dessen bietet MySQL das AUTO_INCREMENT Attribut, womit man ähnliches hinbekommt. Manchmal ist Auto-Increment aber nicht das richtige.
Da ich mySQL verwende (zumindest vorerst), autoincrement für meinen Fall tasächlich nicht das richtige ist und es mir beim überfligen der Artikel schien das sequenz nur auf ein table create anzuwenden ist, versuche ich jetzt nicht dahinter zu kommen was genau eine sequenz ist.
Alexander
Viele Grüße,
Rob
moin,
http://planet.mysql.com/entry/?id=16008 :
Anders als andere DBMSe kennt MySQL keine SEQUENCE Objekte. Statt dessen bietet MySQL das AUTO_INCREMENT Attribut, womit man ähnliches hinbekommt. Manchmal ist Auto-Increment aber nicht das richtige.
will ja nicht kleinlich sein, aber ich wäre sehr vorsichtig eine sequence mit autoincremnt zu vergleichen und die wörter "statt dessen" oder "ähnlich" zu benutzen. eigentlich sind das zwei verschiedene dinge. alles, was du mit auto-increment machen kannst, das bekommst du auch mit sequenzen hin, aber umgekehrt nicht mal ansatzweise.
Ilja
hi,
Gibts also bessere Lösungen
Ja: Einfach nur Loggen. Zählen kannst Du hinterher mit einer zweckmäßigen Abfrage. Das wäre mein Vorschlag für den Fall, dass Du den Zählerstand nicht sofort benötigst.
Hotti
Hi und Danke
hi,
Gibts also bessere Lösungen
Ja: Einfach nur Loggen. Zählen kannst Du hinterher mit einer zweckmäßigen Abfrage. Das wäre mein Vorschlag für den Fall, dass Du den Zählerstand nicht sofort benötigst.
Hmm.. das ergibt auch schöne Möglichkeiten.
Würde doch aber für den geschilderten Fall die Redundanz in der DB (durch die 2 Textfelder) enorm erhöhen.
Also müsste die lokalisierung in einer weiteren Tab abgelegt sein, oder hartgecodet im quelltext, was beides zu vermeiden ist. :(
Hotti
Viele Grüße,
Rob
h1,
Hmm.. das ergibt auch schöne Möglichkeiten.
das denke ich aber auch ;)
Würde doch aber für den geschilderten Fall die Redundanz in der DB (durch die 2 Textfelder) enorm erhöhen.
Also müsste die lokalisierung in einer weiteren Tab abgelegt sein, oder hartgecodet im quelltext, was beides zu vermeiden ist. :(
Das wiederum verstehe ich nicht wirklich, aber mir ist nochwas eingefallen:
Zweige einen Kind-Prozess ab, der kann dann in aller Ruhe die DB beschreiben.
Hotti
Hello,
dafür gibt es Stored Procedures und Triggers.
Lass den (Select-)Zugriff nur über eine Stored Procedure zu. Diese kann dann in einer zweiten Tabelle automatisch das Logging betreiben. Dort kannst Du entweder Updates durchführen, oder besser noch, reine Bewegungsdaten schreiben lassen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Morgen,
dafür gibt es Stored Procedures und Triggers.
Lass den (Select-)Zugriff nur über eine Stored Procedure zu. Diese kann dann in einer zweiten Tabelle automatisch das Logging betreiben. Dort kannst Du entweder Updates durchführen, oder besser noch, reine Bewegungsdaten schreiben lassen.
Sorry, ich muss jetzt nochnmal dumm nachfragen, weil ich da noch nicht so pro bin. :)
Sowohl trigger als auch SP sind sql-Befehl-abhängig, richtig?
Ich möchte ja nur den Aufruf einer Funktion loggen (zB. in PHP "zeige_wetterdaten()"), diese kann aber hunderte SQL Abfragen beinhalten, also potentiell auch hundertfach das log inkrementieren. Oder es wird eine Extra-log-Funktion gestartet die wiederum den Trigger startet, der dann das log schreibt (was in dem Trigger genau passieren soll ist dann auch wieder genau die Frage im erster Post)
Tom vom Berg
Danke und Viele Grüße,
Rob
Hello,
Ich möchte ja nur den Aufruf einer Funktion loggen (zB. in PHP "zeige_wetterdaten()"), diese kann aber hunderte SQL Abfragen beinhalten, also potentiell auch hundertfach das log inkrementieren.
Dann kannst Du doch einmal bei Aufruf Bewegungsdaten schreiben. Die sind meistens zeitunkritisch, wenn sie nicht differenziell sind, also gleichzeitig abhängig von einer Abfrage auf dieselbe Tabelle sind.
Oder es wird eine Extra-log-Funktion gestartet die wiederum den Trigger startet, der dann das log schreibt (was in dem Trigger genau passieren soll ist dann auch wieder genau die Frage im erster Post)
Das ist dann i.d.R. überflüssig.
Die SP sind nur ein sauberer Weg für die Entkoppelung der Datandefinitionsschicht von der Datenzugriffsschicht der DB. Außerdem kann man mit ihnen auch vertikale Rechte ermöglichen, die in DBMS meistens nicht implementiert sind.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg