DB-Zeilen aus mySQL per PHP löschen

[Stan]

Hallo,
ich habe ein Script geschrieben, dass mir einige Zeilen einer DB ausgeben soll und falls das Datum in Spalte "Expiration" älter als 2 Wochen ist, die Zeile rauslöschen:
Die Spalte "Expiration" in der DB ist als Datetime angelegt und Standard 0000-00-00 00:00:00

  
 $query="SELECT * FROM jos_vm_product_category_xref WHERE category_id=51 AND expiration!=''";  
 $result=mysql_query($query);  
 while($row = mysql_fetch_assoc($result)){  
 $expire_date = strtotime($row['expiration']);  
  
       if($expire_date-14*86400 <= time()){  
 	$query="DELETE FROM jos_vm_product_category_xref WHERE id=".$row['id'];  
        mysql_query($query);		  
        echo $query.'<br />';  
 	} 	  
 }  

Das klappt leider nicht, die Zeile wird nicht gelöscht.
Ich bekomme beim Echo nur ausgegeben:
"DELETE FROM jos_vm_product_category_xref WHERE id="

Hat jemand ne Idee?

Danke und Grüße
Stan

[suit]

Hat jemand ne Idee?

Warum lässt du das niht allegemein die Datenbank machen - wozu ist der SELECT vorher gut? Das führt nur zu einem TOCTTOU-Problem. In dem Fall wirds zwar wurscht sein, aber von der Performance ist deine Lösung auch nicht grade der Renner.

DELETE FROM jos_vm_product_category_xref WHERE category_id = 51 AND expiration <= UNIX_TIMESTAMP()+14*86400;

[Matti Mäkitalo]

Hi,

DELETE FROM jos_vm_product_category_xref WHERE category_id = 51 AND expiration <= UNIX_TIMESTAMP()+14*86400;

habe jetzt gerade kein MySQL zur Hand, aber ich nehme mal an, dass es schneller wird, wenn man den expiration-Zeitstempel vorher berechnet und dann nur noch mit einer Konstante vergleicht. Dies dürfte es MySQL einfacher fallen lassen, einen etwaigen Index auf expiration zu nutzen.

Bis die Tage,
Matti

[Stan]

habe jetzt gerade kein MySQL zur Hand, aber ich nehme mal an, dass es schneller wird, wenn man den expiration-Zeitstempel vorher berechnet und dann nur noch mit einer Konstante vergleicht. Dies dürfte es MySQL einfacher fallen lassen, einen etwaigen Index auf expiration zu nutzen.

Bis die Tage,
Matti

Genau, so habe ich es jetzt gemacht, danke allen!

[suit]

habe jetzt gerade kein MySQL zur Hand, aber ich nehme mal an, dass es schneller wird, wenn man den expiration-Zeitstempel vorher berechnet und dann nur noch mit einer Konstante vergleicht. Dies dürfte es MySQL einfacher fallen lassen, einen etwaigen Index auf expiration zu nutzen.

MySQL kann _sehr_ gut rechnen - das fällt in den Bereich Microoptimierung, ich glaube kaum, dass PHP signifikant schneller ist als MySQL wenn es um simple Subtraktionen geht

Dazuzusagen ist aber noch: time() und UNIX_TIMESTAMP() liefern anderer Werte - einerseits gibt es eine Unterschiedung zwischen signed und unsigned - sprich, während time() Werte vor 1970 Darstellen kann, kann dafür UNIX_TIMESTAMP() werte nach 2038 (plus ein paar zerquetschte) darstellen.

Und natürlich ist die Zeitzone ggf. abweichend, das lässt sich aber mit CONVERT_TZ() fixen.

Im vorliegenden Fall dürfte aber beides ziemlich Wurst sein.

[dedlfix]

Hi!

habe jetzt gerade kein MySQL zur Hand, aber ich nehme mal an, dass es schneller wird, wenn man den expiration-Zeitstempel vorher berechnet und dann nur noch mit einer Konstante vergleicht. Dies dürfte es MySQL einfacher fallen lassen, einen etwaigen Index auf expiration zu nutzen.
MySQL kann _sehr_ gut rechnen - das fällt in den Bereich Microoptimierung, ich glaube kaum, dass PHP signifikant schneller ist als MySQL wenn es um simple Subtraktionen geht

Das kommt drauf an, wie MySQL mit dem UNIX_TIMESTAMP() in dem Statement umgeht. Wenn es das für jeden Datensatz einzeln berechnet, dann kann MySQL zwar weiterhin schnell rechnen, muss aber einen Full-Table-Scan machen und kann keinen Index verwenden, was dann schnell nicht mehr unter Mikrooptimierung fällt. Wenn der Wert nur einmal beim Statement-Parsen berechnet wird, dann findet auch die anschließende Rechnung nur einmal statt, und mit diesem konstanten Wert kann ein Index verwendet werden.

Was nun von beiden eintritt, konnte ich nicht herausfinden, entweder schweigt das Handbuch oder versteckt die Information an einer Stelle, an der ich nicht nachgeschaut habe.

Lo!

[suit]

Was nun von beiden eintritt, konnte ich nicht herausfinden, entweder schweigt das Handbuch oder versteckt die Information an einer Stelle, an der ich nicht nachgeschaut habe.

Mir ist dazu auch nichts bekannt - aber nach gesunden Menschenverstand zu Urteilen sollte zumindest statische Teile zuerst 1x berechnet werden. Aber so eine Annahme muss nix heissen.