Ich erstelle also ein System, das 50-150 Datensätze gleichzeitig aus einer Tabelle holt und sie dem Benutzer anzeigt, und ich versuche, für jeden Datensatz eine Anzahl von Ansichten zu behalten.
Ich dachte, der effizienteste Weg bestünde darin, eine MEMORY-Tabelle zu erstellen, die ich mit INSERT INTO in die IDs der Zeilen ziehe und dann eine Cron-Funktion habe, die regelmäßig die Aggregation der View-IDs durchführt und den Speicher löscht Tabelle, aktualisiert das Original mit der neuesten Ansicht zählt. Dadurch wird vermieden, dass die Tabelle, auf die am wahrscheinlichsten zugegriffen wird, ständig aktualisiert wird. Daher sperre ich bei jeder Abfrage nicht 150 Zeilen gleichzeitig (oder die gesamte Tabelle, wenn ich MyISAM verwende).
Grundsätzlich erklärte die Methode hier .
Allerdings würde ich das natürlich zur gleichen Zeit tun, wenn ich die Datensatzinformationen zur Ansicht abrufe, und ich möchte vermeiden, eine zweite, separate Abfrage auszuführen, nur um die gleichen Daten für ihre Zählungen zu erhalten .
Gibt es eine Möglichkeit, ein Dataset auszuwählen, dieses Dataset zurückzugeben und gleichzeitig eine einzelne Spalte aus diesem Dataset in eine andere Tabelle einzufügen?
Es sieht so aus, als hätte PostgreSQL etwas, was ich mit dem Schlüsselwort RETURNING erreichen möchte, aber ich benutze MySQL.
Zunächst würde ich der Tabelle Main keine Zählersäule hinzufügen. Ich würde eine separate Tabelle Audit erstellen, die ID des Elements aus der Tabelle Main plus mindestens Zeitstempel enthalten würde, wenn diese ID angefordert wurde. Im Wesentlichen speichert Audit table eine Historie von Anfragen. In diesem Ansatz können Sie einfach viel interessantere Berichte erstellen. Sie können immer die Gesamtsummen pro Artikel berechnen und auch Zusammenfassungen nach Tag, Woche, Monat usw. pro Artikel oder über alle Artikel hinweg berechnen. Abhängig von der Datenmenge können Sie Audit-Einträge, die älter sind als ein bestimmter Schwellenwert (ein Monat, ein Jahr usw.), regelmäßig löschen.
Sie können auch einfach weitere Informationen in Audit table nach Bedarf speichern, z. B. Benutzer-ID, um Statistiken pro Benutzer zu berechnen.
Um Audit table "automatisch" zu füllen, würde ich eine gespeicherte Prozedur erstellen. Der Client-Code würde diese gespeicherte Prozedur aufrufen, anstatt die ursprüngliche SELECT auszuführen. Gespeicherte Prozedur würde genau das gleiche Ergebnis zurückgeben wie das ursprüngliche SELECT , würde aber auch notwendige Details zur Tabelle Audit transparent zum Client-Code hinzufügen.
Nehmen wir an, dass Audit table wie folgt aussieht:
und Ihr Haupt SELECT sieht so aus:
Um sowohl INSERT als auch SELECT in einer Anweisung in SQL Server auszuführen, verwende ich OUTPUT -Klausel, in Postgres - RETURNING -Klausel, in MySQL - ??? Ich denke nicht, dass es so etwas gibt. Also, MySQL-Prozedur würde mehrere separate Anweisungen haben.
MySQL
Machen Sie zunächst Ihre SELECT und fügen Sie Ergebnisse in eine temporäre ein (möglicherweise Speicher) Tabelle. Kopieren Sie dann die Element-IDs aus der temporären Tabelle in Audit table. Dann SELECT aus der temporären Tabelle, um das Ergebnis an den Client zurückzugeben.
SQL Server (nur um Sie zu ärgern. Diese einzelne Anweisung hat sowohl INSERT als auch SELECT )
Sie können Audit table so belassen, wie sie ist, oder Sie können cron einrichten, um es regelmäßig zusammenzufassen. Es hängt wirklich von der Menge der Daten ab. In unserem System speichern wir einzelne Zeilen für eine Woche, plus wir fassen Statistiken pro Stunde zusammen und behalten sie für 6 Wochen, plus wir behalten tägliche Zusammenfassung für 18 Monate bei. Aber, wichtiger Teil, all diese Zusammenfassungen sind separate Audit -Tabellen, wir behalten Auditing-Informationen nicht in der Tabelle Main , so dass wir sie nicht aktualisieren müssen.
Joe Celko hat es sehr gut in SQL erklärt Stilgewohnheiten: Angriff der Skeuomorphs :
Gehen Sie nun zu einem beliebigen SQL-Forum, um die Einträge zu suchen. Du wirst finden Tausende von Postings mit DDL, die Spalten mit dem Namen
createdbyenthalten,createddate,modifiedbyundmodifieddatemit diesem bestimmten Metadaten am Ende der Zeilendeklaration. Es ist das alte Magnetband Header-Label in einer neuen Sprache geschrieben! Deja Vu!Die Header-Datensätze wurden nur einmal auf einem Band angezeigt. Aber diese Metadaten Werte erscheinen immer wieder in jeder Zeile der Tabelle. Einer der wichtigsten Gründe für die Verwendung von Datenbanken (nicht nur SQL) war die Beseitigung der Redundanz aus den Daten; Dies fügt nur mehr Redundanz hinzu. Aber jetzt denke darüber nach Was passiert mit dem Audit-Trail, wenn eine Zeile gelöscht wird? Was passiert mit der Audit-Trail, wenn eine Zeile aktualisiert wird? Der Weg ist zerstört. Das Prüfdaten sollten vom Schema getrennt sein. Würdest du das Protokoll schreiben? Datei auf dem gleichen Laufwerk wie die Datenbank? Würde ein Buchhalter lassen die gleiche Person genehmigen und eine Zahlung erhalten?
Sie fragen sich, ob MySQL einen SELECT-Trigger unterstützt. Es tut es nicht. Sie müssen dies als zwei Abfragen tun, aber Sie können diese in eine gespeicherte Prozedur stecken - dann können Sie den Bereich übergeben, den Sie abrufen, lassen Sie beide die Ergebnisse zurück und machen Sie die INSERT in die andere Tabelle. p>
Aktualisierte Antwort mit Skeleton-Beispiel für gespeicherte Prozedur:
%Vor%