Multiple SQL Querys auf einmal?

[69bruno]

und veraltete Einträge werden gelöscht

OK, sowas kenne ich nicht, bei mir gibt es nur das automatische Datensätze hinzufügen.
Löschen einzelner DS war bei mir immer zu vermeiden. Deswegen habe ich gerne mit temporären Tabellen gearbeitet (z.B. täglich angelegte) und habe Datensätzen die nicht mehr gültig waren ein entsprechendes Merkmal verpasst. Lese aber interessiert weiter mit.

[oxpus]

@LukeWCS

Während einer Transaktion führt die Datenbank nur die gegebenen Abweisungen aus, bis die Transaktion wieder beendet wird.
Letzteres ist auch wichtig, da ansonsten die Datenbank nur für den einen "Kanal" zugänglich wäre und ansonsten bis zu einem möglichen Timeout (mit anschließendem Rollback der Transaktion) normalerweise keine weiteren Befehle ausführt; zumindest in den durch eine Transaktion "gesperrten" Objekten.

Solange also die Transaktion dauert, wartet jede weitere SQL-Anweisung auf die Ausführung.
Daher kann diese Methode noch am ehesten genutzt werden, logisch zusammenhängende und aufeinander basierende Daten konsistent zu bearbeiten, ohne dass jemand Drittes dazwischenfunkt.

phpBB verwendet diese Methode selber, um Aktionen wie das Synchronisieren von Themen, das Anlegen von Benutzern etc. auch mit allen anhängenden Daten korrekt in der Datenbank umzusetzen.
Denn bei solchen Themen kommt es schließlich darauf an, dass nach der Transaktion über mitunter zahlreichen SQL-Anweisungen am Ende alle Daten in sich schlüssig in der Datenbank vorhanden sind.

Allerdings habe ich etwas Bauchschmerzen damit, wenn Du mit der Extension einen Primärindex neu initiieren willst, auf den sich normalerweise SQL-Anweisungen stützen, um gezielt Daten auszulesen oder zu bearbeiten.

Ich hoffe nur, Du weißt was Du tust, denn ansonsten könnte es logische Fehler in den Daten oder gar Fehlermeldungen aus der Datenbank hageln, wenn wartende SQL-Anweisungen falsche Bezüge zu einem neu aufgebauten Index verwenden.
Denn merke:
Während eine Transaktion läuft, nimmt die Datenbank selbstverständlich neue Befehle an, führt diese aber erst nach der Transaktion aus.
Die werden ja nicht verhindert, sondern nur in die Warteschlange gestellt...

[LukeWCS]

Allerdings habe ich etwas Bauchschmerzen damit, wenn Du mit der Extension einen Primärindex neu initiieren willst, auf den sich normalerweise SQL-Anweisungen stützen, um gezielt Daten auszulesen oder zu bearbeiten.

Ich hoffe nur, Du weißt was Du tust, denn ansonsten könnte es logische Fehler in den Daten oder gar Fehlermeldungen aus der Datenbank hageln, wenn wartende SQL-Anweisungen falsche Bezüge zu einem neu aufgebauten Index verwenden.

Dein Einwand ist berechtigt, aber die Ext selbst nutzt den Index nicht. Das war natürlich das erste was ich überprüft habe, bevor ich anfing nach Reset Lösungen für den auto_increment Index zu suchen. Das Ganze ist auch ausgiebig getestet, wie erwartet keine Probleme damit wenn man den Index neu aufbaut. Der Index dient also quasi nur zum separieren der Records, zu mehr nicht.

Danke für deine ausführlichen Infos!

Der Punkt ist, deine/Crizzo's Idee hat bei mir beim testen für Verwirrung gesorgt, weil ein sql_transaction('commit') gar nicht notwendig war, die Queries wurden trotzdem ausgeführt. Ich bin davon ausgegangen, das man mit sql_transaction('begin') eine Art Job-List erstellt, die man dann per sql_transaction('commit') ausführen kann. Laut Test verhält sich das jedoch anders, weshalb ich davon ausgegangen bin, das die Transactions Methode doch nicht das richtige ist.

Und genau das frage ich mich noch immer. Wieso wird das auch dann ausgeführt, wenn keinsql_transaction('commit') erfolgt? Doc hatte zwischenzeitlich den Gedanken, ob das der DB Layer von phpBB automatisch erledigt, wenn sql_transaction('begin') ausgeführt wurde. Wie siehst du das?

[oxpus]

Der Punkt ist, deine/Crizzo's Idee hat bei mir beim testen für Verwirrung gesorgt, weil ein sql_transaction('commit') gar nicht notwendig war, die Queries wurden trotzdem ausgeführt.

Jein.
Wenn nach dem logischen Ende der SQL-Anweisungen einer Transaktion keine weiteren SQL-Anweisungen vor dem Schließen der Datenbankverbindung vorkommen, wäre ein sql_transaction('commit') nicht notwendig, da das Schließen der Datenbankverbindung auch immer ein COMMIT auslöst und damit die Datenbank eine begonnene Transaktion ausführen lässt.

Dennoch sollte man Transaktionen immer schnellstens und damit sauber mit einem COMMITbeenden, da bei einem Fehler zwischen dem logischen Ende der Transaktion und dem Schließen der Datenbankverbindung eine begonnene Transaktion eben nicht sofort ausgeführt wird.
Das kann auch ein simpler PHP-Fehler sein, da dieser die Datenbankverbindung nicht zwangsweise schließt und somit auch ein an dieser Stelle unerwünschtes ROLLBACK der bis dahin möglicherweise erfolgreichen Transaktion auslösen könnte.

Allerdings bin ich mir nicht sicher, ob eine Transaktion auch davor schützt, wenn damit ein neu aufzubauender Tabellen-Index ausgeführt werden soll. Schließlich ist eine Transaktion eher für die "üblichen" SQL-Abweisungen wie DELETE, UPDATE, INSERT oder REPLACE gedacht und weniger für ein ALTER TABLE oder gar ein DROP INDEX, CREATE INDEX, ALTER INDEX.
Wobei sich alle beliebigen SQL-Anweisungen in einer Transaktion zusammenfassen lassen. Und wenn diese logisch korrekt aufeinander aufbauen, sehe ich auch kein Problem, am Ende der logischen Transaktion auch einen Index neu zu setzen.

Dennoch:
Während der Index einer Tabelle in einer Transaktion bearbeitet wird, nimmt die Datenbank ja auch immer neue Befehle entgegen.
Aber was passiert dabei, wenn die Transaktion beendet ist und die geänderten Primärschlüssel nicht mehr zu den nachfolgenden SQL-Anweisungen passen?
Innerhalb einer Transaktion kann man das noch kontrollieren, aber die wartenden SQL-Anweisungen kennen den neuen Index nicht, wenn dieser in einer Transaktion geändert wurde.
Allerdings trifft dieses Problem auch bei einzeln ausgeführten SQL-Anweisung zu, welche einen Index manipuliert. Von daher gäbe es keinen Unterschied, ob ein Befehl für den Index innerhalb oder vor / nach einer Transaktion ausgeführt wird...
Allein daher wäre aber ein COMMIT der Transaktion wiederum sinnvoll, insbesondere, wenn ein Tabellen-Index geändert wird, um möglichst keine oder nur einzelne Folgefehler zu erhalten.

[69bruno]

Stünde denn einer Änderung der Tabellenstruktur etwas entgegen, dass es keine "gelöschten" DS mehr gibt und täglich eine neue Tabelle angelegt wird ? Veraltete Tabellen können ja komplett gelöscht werden. Dann würde es doch gar kein Problem mit dem autoincrement geben.....

[Dr.Death]

Oder man nimmt sich die phpbb_session Tabelle als Vorbild und nutz keinen autoincrement, der sich irgendwann überschlagen könnte.

Vielleicht einfach die bisherige session_id mit übernehmen und auch als Primar key verwenden.(non unique 0).


Eine Tabelle zur Laufzeit löschen und neu zu erstellen ist ein schlechter Vorgang, da parallel ja noch Daten einfliessen könnten.

[69bruno]

Eine Tabelle zur Laufzeit löschen und neu zu erstellen ist ein schlechter Vorgang, da parallel ja noch Daten einfliessen könnten.

Nö, wenn ich die Tabelle mit Datumspräfix täglich erstelle, kann ich die vom Vortag löschen,weil da keine Daten mehr einfließen können. Bedient werden nur Tabellen, die das Tagesdatum tragen.

[LukeWCS]

Wenn nach dem logischen Ende der SQL-Anweisungen einer Transaktion keine weiteren SQL-Anweisungen vor dem Schließen der Datenbankverbindung vorkommen, wäre ein sql_transaction('commit') nicht notwendig, da das Schließen der Datenbankverbindung auch immer ein COMMIT auslöst und damit die Datenbank eine begonnene Transaktion ausführen lässt.

Das war das fehlende Puzzleteil, danke.

Dennoch sollte man Transaktionen immer schnellstens und damit sauber mit einem COMMITbeenden, da bei einem Fehler zwischen dem logischen Ende der Transaktion und dem Schließen der Datenbankverbindung eine begonnene Transaktion eben nicht sofort ausgeführt wird.
Das kann auch ein simpler PHP-Fehler sein, da dieser die Datenbankverbindung nicht zwangsweise schließt und somit auch ein an dieser Stelle unerwünschtes ROLLBACK der bis dahin möglicherweise erfolgreichen Transaktion auslösen könnte.

Jupp, die Rollback Funktion wäre in dem Fall wirklich unerwünscht, denn der Code sollte auf jeden Fall ausgeführt werden. Damit du mich nicht missverstehst; ich hatte nicht vor den COMMIT einfach wegzulassen. Das diente nur zum testen und verstehen was bei einer Transaktion passiert. Ich muss den COMMIT auf jeden Fall senden, weil die Reset Funktion beim Event Aufruf gleich als erstes ausgeführt werden soll, wenn der AI Wert eine bestimmte Grenze überschritten hat. Und direkt danach erfolgt die normale Prozedur, bei der auch sofort wieder Änderungen an der Tabelle vorgenommen werden können/müssen.

Allerdings bin ich mir nicht sicher, ob eine Transaktion auch davor schützt, wenn damit ein neu aufzubauender Tabellen-Index ausgeführt werden soll. Schließlich ist eine Transaktion eher für die "üblichen" SQL-Abweisungen wie DELETE, UPDATE, INSERT oder REPLACE gedacht und weniger für ein ALTER TABLE oder gar ein DROP INDEX, CREATE INDEX, ALTER INDEX.
Wobei sich alle beliebigen SQL-Anweisungen in einer Transaktion zusammenfassen lassen. Und wenn diese logisch korrekt aufeinander aufbauen, sehe ich auch kein Problem, am Ende der logischen Transaktion auch einen Index neu zu setzen.

Okay, es ist also nicht sicher, dass eine Transaktion meinen Reset Code schützen würde? Denn ich benötige dabei sowohl ein UPDATE als auch ein ALTER TABLE.

Dennoch:
Während der Index einer Tabelle in einer Transaktion bearbeitet wird, nimmt die Datenbank ja auch immer neue Befehle entgegen.
Aber was passiert dabei, wenn die Transaktion beendet ist und die geänderten Primärschlüssel nicht mehr zu den nachfolgenden SQL-Anweisungen passen?
Innerhalb einer Transaktion kann man das noch kontrollieren, aber die wartenden SQL-Anweisungen kennen den neuen Index nicht, wenn dieser in einer Transaktion geändert wurde.

Wie gesagt, dieser Index selbst wird von der Ext gar nicht verwendet. Wie sich das aber seitens der DBMS selbst verhält, weiss ich stand jetzt nicht. Meine Tests gingen nur in die Richtung festzustellen, ob die Ext ein Problem mit geändertem Index hat. Das fand jedoch nur in einem lokalen TB statt, wo es logischerweise ausser mir niemand gibt der parallele/konkurrierende SQL Queries initiieren würde.

Schlussendlich geht es mir hier in dem Thema vor allem eben um das Thema multiple SQL Queries, oder besser gesagt um geschützte multiple SQL Queries. Die Reset Funktion für einen auto_increment Wert ist dabei zwar das Ziel, aber trotzdem nur zweitrangig.

Stünde denn einer Änderung der Tabellenstruktur etwas entgegen, dass es keine "gelöschten" DS mehr gibt und täglich eine neue Tabelle angelegt wird ? Veraltete Tabellen können ja komplett gelöscht werden. Dann würde es doch gar kein Problem mit dem autoincrement geben.....

Das geht schon alleine deswegen nicht, weil der Endbenutzer zwischen zwei Zeit-Modellen auswählen kann: Heute und Zeitraum. Und bei letzterem kann er auch frei definieren, wie gross dieser sein soll. Präzise in Stunden, Minuten und Sekunden.

Oder man nimmt sich die phpbb_session Tabelle als Vorbild und nutz keinen autoincrement, der sich irgendwann überschlagen könnte.

Vielleicht einfach die bisherige session_id mit übernehmen und auch als Primar key verwenden.(non unique 0).

Das klingt sehr interessant! Wenn es einen Weg geben würde den auto_increment Wert ganz loszuwerden, würde ich diesen sofort gehen.

[oxpus]

Die Session-ID ist ja bereits eindeutig auf den User gemünzt, benötigt also keinen weiteren Primärschlüssel.
Daher ist dieser bereits über die Session-ID darstellbar.
Das würde das Problem, einen Index neu zu erstellen, beseitigen.

Und dann wäre die Transaktion wieder zusammenhängend und problemlos ausführbar, ohne das dort jemand reinkrätscht oder diese Aktion Fehler verursachen könnte.

[LukeWCS]

Die session_id ist leider auch nicht ganz unproblematisch. Ich muss mich erstmal wesentlich genauer mit der Thematik Primärschlüssel auseinandersetzen, bevor ich da eine Änderung vornehmen kann. Als vorläufigen Workaround erhöhe ich beim nächsten Update einfach von MEDIUMINT auf INT. Damit ist das Problem vorläufig vom Tisch und ich habe genug Zeit mich mit dem Thema genauer zu befassen.

Was Transaktionen angeht: wieder viel gelernt und das werde ich mit Sicherheit noch brauchen können. Daher einen FETTEN Dank an dich oxpus für die vielen Infos und Überlegungen.

Auch Danke an alle die Vorschläge gebracht und mitgegrübelt haben!