nicht angemeldet
Hi!
Wenn der Datenbestand nicht allzu groß ist, kannst du die Daten in einem Rutsch abfragen und die Auswertung auf dem Client machen. Ansonsten eben viele Statements absetzen.
Aus Performancegründen würde ich exakt umgekehrt argumentieren. Wenn der Datenbestand klein ist, dann tut ein "SELECT ... WHERE parentId = ..." + "DELETE ... WHERE id =..." noch nicht sehr weh.
Aber es wird für die Datenbank nahezu unmöglich, wenn man tausend (oder mehr) Postings hat, und diese mit tausend SELECT und tausend DELETE zu löschen versucht. Gerade in so einem Fall ist es im Prinzip Pflicht, mit so wenig Querys wie möglich den maximalen Effekt zu erzielen. Im Idealfall also mit nur einem einzigen SELECT (die Eltern-Kind-Beziehung bastelt man sich dann im Speicher zusammen) und mit nur einem einzigen "DELETE ... WHERE id IN (1,2,3,...)".
Ja, deine Argumente sind nicht von der Hand zu weisen. Der Idealfall ist wohl bei vielen wie bei wenig Daten ein SELECT und ein DELETE. Meine Überlegungen gingen eher davon aus, dass bei einer großen Menge der zur Verfügung gestellte Speicher nicht ausreichen könnte, um sämtliche Datensätze darin abzulegen und zu durchsuchen, inklusive Ablage der Zwischenergebnisse. Dazu müsste aber die Datenmenge schon recht enorm und/oder der Speicher sehr klein sein, denn ID plus Parent-ID sind im Prinzip grad mal zwei Integerwerte. In dem Fall stößt man mit vielen kleinen Schritten nicht an die Speichergrenze, aber an die der Zumutbarkeit. Die Frage dürfte jedoch auch bei ausreichend Speicher sein, was länger dauert: PHP einem großen Datenhaufen beackern zu lassen oder die Aufgabe dem DBMS zu übergeben und sich dafür eine Stored Procedure zu schreiben.
Lo!
MudGuard