SQL "ON DUPLICATE KEY UPDATE" - tatsächlich hinzugefügte/geänderte Zeilen

[RemoteC]

Hallo,

ich habe in einem PHP-Skript eine generierte SQL-Query, die bestimmte Datensätze aus einer Tabelle A ausliest und in eine andere Tabelle B einfügt und ein paar Flags dort setzt. Wenn der Gewünschte Datensatz (UID) schon in der Tabelle B vorhanden ist, kann er natürlich nicht mehr hinzugefügt werden sondern es soll nur das entsprechende Flag gesetzt werden. Abstrahiert:

INSERT IGNORE INTO TableA (UID, Flag1, Flag2)
SELECT b.UID, 1, 1
FROM TabelB b
ON DUPLICATE KEY UPDATE
Flag1 = 1, Flag2 = 1;

Wie kann ich jetzt eine Ausgabe erzielen die ca. so aussieht:

Anzahl neu hinzugefüger Datensätze: 99
Anzahl aktualisierte Datensätze: 302
= Anzahl betroffener Datensätze: 401

Diesen Code habe ich schon ausprobiert: php - MySQL on duplicate key update + affected row count - Stack Overflow aber da kommen nicht die richtigen Zahlen raus.

 

[Fluffy]

SELECT flagset.res, flatnotset.res, flatset.res + flagnotset.res from ( select count(*) as res from tableA where <conditionSet>) flagset inner join (select
count(*) as res from tableA where <conditionNotSet>) flagnotset;

Man kann es auch mittels GroupBy machen, aber dann würde man soweit ich weiss mehrere Queries brauchen.
Gruß

Fluffy

 

[RemoteC]

Danke für die Antwort!

Wenn ich die Query richtig interpretiere macht die nichts anderes als eigenständig auszulesen bei wie vielen Einträgen ein Flag gesetzt wurde.

Ich hatte gehofft, dass ich diese Zahlen aus MySQL-Variablen bzw. mittels PHP-Funktion auslesen kann ohne weitere Query. So wie der Ansatz beim Link auf Stack Overflow. Nachdem die Queries/Conditions recht lang sind und das INSERT eine Zeit braucht will ich weitere Abfragen, die die Ausführung verzögern, vermeiden.

 

[Fluffy]

Klar kann man alles machen.
Man muss dann halt nur einen entsprechenden Counter schreiben, oder aber eine entsprechende Funktion definieren.

Was meinst du mit dem Ansatz vom Link auf Stack Overflow?(Link wäre interessant)
Die müssen doch auch die Daten irgendwo speichern.
Klar sind Subselects nicht unbedingt geil, aber lassen sich manchmal nicht vermeiden, genauso wenig wie mehrere SQL-Queries, toll wäre eine einzelne Query mit GroupBy ohne Subselect, aber das geht nicht(lasse mich hier gerne eines besseren belehren).

Abgesehen davon ist Webentwicklung nicht unbedingt Performancesache.
Klar Responsive-Webdesign, schöne schnell reagierende Oberflächen, aber wenn man sich vor Augen führt, das das Signal mal gut und gerne um den halben Globus geht, und das dann auch mal gute 100+ ms dauert, da macht das Warten auf ein Insert bzw. eine komplexe Query auch nichts mehr, zumal die DBMS heute schon sehr schnell sind.
Alles andere, wäre gehacke und auf lange Sicht schlecht wartbar, bzw. skaliert nicht gut.
Abgesehen davon kann man da auch noch viel drehen, den richtigen Engine für die Tables auswählen, ggf. schon Ausgaben abschicken bevor zeitraubende Operationen erfolgen, die Ausgaben aufsplitten und die Oberfläche mittels JS in mehreren Schritten aufbauen, bei bestimmten Bereichen(nicht unbedingt Webentwicklung) kann man auch "nicht blockierend" Programmieren.

Ich würde mich also (noch) nicht mit einzelnen Operationen aufhalten, denn wenn jetzt schon(während der Entwicklung) Performanceprobleme auftreten dann hat das _meistens_ mit den Design der Anwendung zu tun.
Gruß

Fluffy